[Bug 60104] New: ws2_32: socket readiness notifications (WSAIoctl IOC_VENDOR 210 / ProcessSocketNotifications) unimplemented: World of Warcraft 12.x login takes minutes (30s timeout per round-trip)

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
  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.