http://bugs.winehq.org/show_bug.cgi?id=60104 Bug ID: 60104 Summary: ws2_32: socket readiness notifications (WSAIoctl IOC_VENDOR 210 / ProcessSocketNotifications) unimplemented: World of Warcraft 12.x login takes minutes (30s timeout per round-trip) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs@list.winehq.org Reporter: renatoiwa@gmail.com Target Milestone: --- Distribution: --- Created attachment 81653 --> http://bugs.winehq.org/attachment.cgi?id=81653 unimplemented ioctl trace Product: Wine Component: winsock Version: 11.0 (observed under Proton Experimental; Wine 11.0 per game's gx.log) Severity: normal Hardware/OS: x86_64 / Linux 7.1.5-arch1-2 --- Description --- World of Warcraft retail 12.x ("Midnight") introduced a new network layer (Blizzard "bsSocket", also used by the Battle.net launcher) that registers each socket for readiness notifications via: WSAIoctl(s, _WSAIOR(IOC_VENDOR, 210), ...) -> NtDeviceIoControlFile AFD ioctl 0x120348 Wine logs: fixme:winsock:WSAIoctl unimplemented ioctl _WSAIOR(IOC_VENDOR, 210) fixme:winsock:server_ioctl_sock Unsupported ioctl 0x120348 (device=0x12 access=0 func=0xd2 method=0) This appears to be the Windows 10 2004+ "Winsock socket state notifications" mechanism (ProcessSocketNotifications / SOCK_NOTIFY_REGISTRATION, completion-port based: https://learn.microsoft.com/en-us/windows/win32/winsock/winsock-socket-state...). ws2_32.spec does not export ProcessSocketNotifications, and the AFD ioctl is rejected. Effect: the game ignores the registration failure. Its network worker threads then block on event waits expecting readiness notifications that are never posted, and every request/response step of the Battle.net login protocol only advances when a ~30 s fallback timeout fires. A login needs 3–5 round-trips → the "Connecting..." screen takes 1.5–3 minutes (and "Retrieving realm list" another 30 s). On Windows the same login is instant. Gameplay after login is unaffected (world-server connection is serviced by a different code path). --- Evidence --- 1) Server replies arrive immediately and sit unread in the socket receive queue (ss -tanpoe sampled ~1/s while stuck on "Connecting..."): auth socket (us.actual.battle.net:1119): 187 bytes arrive 07:53:59.9, drained 07:54:29.5 (~29.6 s later); next step identical. The client's own Connection.log shows protocol steps quantized to EXACTLY 30.000 s (e.g. "OnSendLogon" -> "Logon complete" = 30.000 s to the millisecond). 2) WINEDEBUG=+timestamp,+winsock trace during one such stall (attachment trace-2-30s-stall-socket-0xb24.txt): the auth socket (handle 0xb24) has no WSAEventSelect, no overlapped I/O, and no blocking select() spanning the stall. The recv thread does a non-blocking WS2_recv_base -> STATUS_DEVICE_NOT_READY (data arrived 1.2 s later), then ALL connection threads are completely winsock-silent for ~30 s (parked in NtWaitForMultipleObjects), wake on timeout, and a blind recv drains the queued reply. Sends still work mid-stall. 3) The registration attempt (attachment trace-1-unimplemented-ioctl.txt) is issued at socket-layer init and per-socket by both WoW.exe and Battle.net.exe. 4) Differential inside the same process: logging in by typing credentials at the WoW login screen (which authenticates through a different, non-notification code path) completes the same :1119 auth conversation in ~6 s with the receive queue empty in every sample. Only the launcher-token flow, which depends on the notification mechanism, exhibits the 30 s-per-step behavior. --- Notes for implementation --- A stub returning success would make things worse (the app would still never receive notifications and lose even its current fallback behavior); the mechanism needs actual registration bookkeeping and completion-port posting (readiness events analogous to epoll edge notifications) in wineserver. Reproduction: Battle.net launcher (non-Steam app under Proton or plain Wine) → install World of Warcraft retail 12.x → click Play → observe "Connecting..." for 1–3 minutes, with `ss -tan` on the host showing bytes parked in Recv-Q on the :1119/:443 connections, and the fixmes above in the log. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.