WineHQ
Bug Tracking Database – Bug 35284

 Bugzilla

 

Last modified: 2021-03-20 11:19:17 UTC  

Polar WebSync client 2.8.x fails to communicate with 'polard' service (WS2_AcceptEx with zero 'local_addr_len' parameter)

First Last Prev Next    This bug is not in your last search results.
Bug 35284 - Polar WebSync client 2.8.x fails to communicate with 'polard' service (WS2_AcceptEx with zero 'local_addr_len' parameter)
Polar WebSync client 2.8.x fails to communicate with 'polard' service (WS2_Ac...
Status: CLOSED FIXED
AppDB: Show Apps affected by this bug
Product: Wine
Classification: Unclassified
Component: winsock
1.7.9
x86 Linux
: P2 normal
: ---
Assigned To: Mr. Bugs
https://web.archive.org/web/201707150...
: download, regression
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-01-01 12:18 UTC by Anastasius Focht
Modified: 2021-03-20 11:19 UTC (History)
2 users (show)

See Also:
Regression SHA1: d0009573eea2e5bad3ce810ddfb22fef99fe969c
Fixed by SHA1: 3c64a7c4e241823dd6590c9651693fa325aa2e5d
Distribution: ---
Staged patchset:

Attachments
Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anastasius Focht 2014-01-01 12:18:58 UTC 
Hello folks,

a guy in #winehq reported this problem.

--- quote ---
<focht> this app: http://www.polar.com/en/support/downloads/Polar_WebSync_Software ?
...
<lars_> focht: yes, I downloaded it from there
<lars_> I'm gonna have to fix a crying baby so gtg. Thanks for the help!
...
--- quote ---

He 'fixes' the baby - I take care of the bug (which is much easier) :)

'Polar Daemon' is registered as auto-start Windows service and communicates over sockets with the client (gui app).

Trace log (filtered for service thread 002a to avoid all the noise from other processes/threads):

--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Polar/WebSync

$ WINEDEBUG=+tid,+seh,+relay,+service,+snoop,+winsock, wine ./WebSync.exe >>log.txt 2>&1
...
002a:trace:winsock:WSAStartup verReq=202
002a:trace:winsock:WSAStartup succeeded
002a:Ret  ws2_32.WSAStartup() retval=00000000 ret=10176d80
002a:Call ws2_32.WSADuplicateSocketW(000000b0,00000021,0086e0bc) ret=10176e0d
002a:trace:winsock:WS_DuplicateSocket (unicode 1, socket 00b0, processid 21, buffer 0x86e0bc)
002a:Call KERNEL32.OpenProcess(00000040,00000000,00000021) ret=7e9a49b4
002a:Ret  KERNEL32.OpenProcess() retval=000000b4 ret=7e9a49b4
002a:Call KERNEL32.DuplicateHandle(ffffffff,000000b0,000000b4,0086e0c4,00000000,00000000,00000002) ret=7e9a4a5d
002a:Ret  KERNEL32.DuplicateHandle() retval=00000001 ret=7e9a4a5d
002a:Call KERNEL32.CloseHandle(000000b4) ret=7e9a4a6b
002a:Ret  KERNEL32.CloseHandle() retval=00000001 ret=7e9a4a6b
002a:Ret  ws2_32.WSADuplicateSocketW() retval=00000000 ret=10176e0d
002a:Call ws2_32.WSASocketW(00000002,00000001,00000006,00000000,00000000,00000001) ret=10176e36
002a:trace:winsock:WSASocketW af=2 type=1 protocol=6 protocol_info=(nil) group=0 flags=0x1
002a:trace:winsock:WSASocketW 	created 00b4
002a:Ret  ws2_32.WSASocketW() retval=000000b4 ret=10176e36
...
002a:Call ws2_32.WSAIoctl(000000b4,c8000006,0086e488,00000010,0086e484,00000004,0086e480,00000000,00000000) ret=10204134
002a:trace:winsock:WSAIoctl 180, 0xc8000006, 0x86e488, 16, 0x86e484, 4, 0x86e480, (nil), (nil)
002a:Ret  ws2_32.WSAIoctl() retval=00000000 ret=10204134
002a:Call ws2_32.WSAIoctl(000000b4,c8000006,0086e4a4,00000010,0086e4a0,00000004,0086e480,00000000,00000000) ret=1020415f
002a:trace:winsock:WSAIoctl 180, 0xc8000006, 0x86e4a4, 16, 0x86e4a0, 4, 0x86e480, (nil), (nil)
002a:Ret  ws2_32.WSAIoctl() retval=00000000 ret=1020415f
002a:Call KERNEL32.CreateEventW(00000000,00000001,00000000,00000000) ret=1020418a
002a:Ret  KERNEL32.CreateEventW() retval=000000d0 ret=1020418a
...
002a:trace:winsock:WS2_AcceptEx (b0, b4, 0x148928, 0, 0, 32, 0x86e480, 0x86e46c)
002a:Call ws2_32.WSAGetLastError() ret=102041f3
002a:Ret  ws2_32.WSAGetLastError() retval=00002726 ret=102041f3
002a:Call ws2_32.WSAGetLastError() ret=1020431c
002a:Ret  ws2_32.WSAGetLastError() retval=00002726 ret=1020431c
002a:Call KERNEL32.GetLastError() ret=10204329
002a:Ret  KERNEL32.GetLastError() retval=00002726 ret=10204329
002a:Call KERNEL32.CloseHandle(000000d0) ret=10204350
002a:Ret  KERNEL32.CloseHandle() retval=00000001 ret=10204350
...
002a:Call ws2_32.WSAGetLastError() ret=10204527
002a:Ret  ws2_32.WSAGetLastError() retval=00002726 ret=10204527
...
002a:Call KERNEL32.GetLastError() ret=101d2dbd
002a:Ret  KERNEL32.GetLastError() retval=00002726 ret=101d2dbd
002a:Call msvcp90.??0?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@XZ(0014892c) ret=101d078c
002a:Ret  msvcp90.??0?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@XZ() retval=0014892c ret=101d078c
002a:Call KERNEL32.FormatMessageW(00001300,00000000,00002726,00000409,0086e394,00000000,00000000) ret=101d07ba
002a:Ret  KERNEL32.FormatMessageW() retval=00000000 ret=101d07ba
002a:Call KERNEL32.FormatMessageW(00001300,00000000,00000507,00000409,0086e394,00000000,00000000) ret=101d07e2
002a:Ret  KERNEL32.FormatMessageW() retval=00000000 ret=101d07e2
002a:Call msvcrt._CxxThrowException(0086e400,1029fe24) ret=10204777
002a:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0086e374) ret=7e7813a1
002a:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b83a89f ip=7b83a89f tid=002a
002a:trace:seh:raise_exception  info[0]=19930520
002a:trace:seh:raise_exception  info[1]=0086e400
002a:trace:seh:raise_exception  info[2]=1029fe24
002a:trace:seh:raise_exception  eax=7b826921 ebx=7b8ba000 ecx=19930520 edx=0086e2c4 esi=0086e370 edi=0086e330
002a:trace:seh:raise_exception  ebp=0086e308 esp=0086e2a4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000283 
--- snip ---

The problem is the overly strict parameter check in WS2_AcceptEx():

Source: http://source.winehq.org/git/wine.git/blob/719715c77426c7cb759a012d24f898622db5db6b:/dlls/ws2_32/socket.c#l2361

--- snip ---
2361 static BOOL WINAPI WS2_AcceptEx(SOCKET listener, SOCKET acceptor, PVOID dest, DWORD dest_len,
2362             DWORD local_addr_len, DWORD rem_addr_len, LPDWORD received,
2363             LPOVERLAPPED overlapped)
2364 {
2365     DWORD status;
2366     struct ws2_accept_async *wsa;
2367     int fd;
2368     ULONG_PTR cvalue = (overlapped && ((ULONG_PTR)overlapped->hEvent & 1) == 0) ? (ULONG_PTR)overlapped : 0;
2369
2370     TRACE("(%lx, %lx, %p, %d, %d, %d, %p, %p)\n", listener, acceptor, dest, dest_len, local_addr_len,
2371                                    rem_addr_len, received, overlapped);
2372
...
2384
2385     if ((local_addr_len < sizeof(struct sockaddr_in) + 16)
2386           || (rem_addr_len < sizeof(struct sockaddr_in) + 16))
2387     {
2388         SetLastError(WSAEINVAL);
2389         return FALSE;
2390     }
...
--- snip ---

The app passes zero 'local_addr_len'  which fails the parameter input check.

With that part fixed, the service successfully initializes and the client can communicate with the service over sockets.

The client software (gui wizard) then waits for some USB smart device (Polar RC3 GPS watch) to be plugged in.

---

Unrelated to this service/winsock problem but still useful information:

The service registers a device notification callback which is probably triggered when the device has been recognized (PnP manager).
That stuff is currently missing in Wine but even then ...

'dmesg' output from IRC user:

--- snip ---
    [ 6188.997849] usb 3-2.3: new full-speed USB device number 8 using uhci_hcd
    [ 6189.150832] usb 3-2.3: New USB device found, idVendor=0da4, idProduct=0006
    [ 6189.150838] usb 3-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 6189.150842] usb 3-2.3: Product: Polar RC3 GPS
    [ 6189.150845] usb 3-2.3: Manufacturer: Polar Electro
    [ 6189.150848] usb 3-2.3: SerialNumber: 21BF9A4626001B00
    [ 6199.157802] hid-generic 0003:0DA4:0006.0005: timeout initializing reports
    [ 6199.158076] hid-generic 0003:0DA4:0006.0005: hiddev0,hidraw4: USB HID v1.01 Device [Polar Electro Polar RC3 GPS] on usb-0000:00:1a.0-2.3/input0
--- snip ---

Regards
Comment 1 Anastasius Focht 2014-01-01 12:20:03 UTC 
Hello folks,

filling fields ...

$ sha1sum websync_2.8.1.exe 
0bd3e38b7948bb6fc3671afa631ac6dc30fa74f9  websync_2.8.1.exe

$ du -sh websync_2.8.1.exe 
42M	websync_2.8.1.exe

$ wine --version
wine-1.7.9-286-g8f53710

Regards
Comment 2 Bruno Jesus 2014-01-01 12:24:02 UTC 
This is a regression from my patch:
http://source.winehq.org/git/wine.git/commitdiff/d0009573eea2e5bad3ce810ddfb22fef99fe969c
Comment 3 Bruno Jesus 2014-01-01 12:30:08 UTC 
I thought I had covered all test cases but obviously not, I'll take a look.
Comment 4 Bruno Jesus 2014-01-01 21:23:00 UTC 
Actually the test does exist and it works as expected (at least I think it's the same test):
http://source.winehq.org/source/dlls/ws2_32/tests/sock.c#L5671

I'll download and test the application during the weekend.
Comment 5 Bruno Jesus 2014-01-01 22:43:32 UTC 
Removing or relaxing that check makes tests fail. The problem may be somewhere else, at first I thought WSADuplicateSocket could not be filling the WSAPROTOCOL_INFOW struct correctly (fields iMaxSockAddr,iMinSockAddr) but that was not the case.

AF can you please check if the value used to call the function is static or from a variable? And if it's from a variable does it come from a call to other winsock function?
Comment 6 Anastasius Focht 2014-01-02 03:36:07 UTC 
Hello Bruno,

it seems both, 'dest_len' and 'local_addr_len' are hard-coded to zero.

I attached to the running service and dumped the disassembly from there:

--- snip ---
...
102041AA  MOV DWORD PTR SS:[EBP-4],0
102041B1  LEA EDX,[EBP-58]
102041B4  PUSH EDX                           ; LPOVERLAPPED overlapped
102041B5  LEA EAX,[EBP-44]
102041B8  PUSH EAX                           ; LPDWORD received
102041B9  LEA ECX,[EBP-78]
102041BC  CALL 1000D6F0
102041C1  PUSH EAX                           ; DWORD rem_addr_len
102041C2  PUSH 0                             ; DWORD local_addr_len
102041C4  PUSH 0                             ; DWORD dest_len
102041C6  LEA ECX,[EBP-78]
102041C9  CALL 1000E1B0
102041CE  PUSH EAX                           ; PVOID dest
102041CF  MOV ECX,DWORD PTR SS:[EBP+8]
102041D2  PUSH ECX                           ; SOCKET acceptor
102041D3  MOV EDX,DWORD PTR SS:[EBP-0C8]
102041D9  MOV EAX,DWORD PTR DS:[EDX+4]
102041DC  PUSH EAX                           ; SOCKET listener
102041DD  CALL DWORD PTR SS:[EBP-40]         ; WS2_AcceptEx()
102041E0  MOV DWORD PTR SS:[EBP-5C],EAX
102041E3  CMP DWORD PTR SS:[EBP-5C],0
102041E7  JNE 10204346
102041ED  CALL DWORD PTR DS:[<&WS2_32.#111>] ; WSAGetLastError()
102041F3  MOV DWORD PTR SS:[EBP-0D0],EAX
102041F9  CMP DWORD PTR SS:[EBP-0D0],3E5     ; WSA_IO_PENDING
10204203  JE SHORT 1020421A
10204205  CMP DWORD PTR SS:[EBP-0D0],2746    ; WSAECONNRESET
1020420F  JE 102042E7
...
--- snip ---

Regards
Comment 7 Bruno Jesus 2014-01-02 11:42:57 UTC 
Thank you, the problem is that all parameter tests are wrong. The listener socket is not in listening state, that shadowed all results making we believe they were correct.
Comment 8 Anastasius Focht 2014-02-06 15:14:17 UTC 
Hello folks,

this is fixed by commit http://source.winehq.org/git/wine.git/commit/3c64a7c4e241823dd6590c9651693fa325aa2e5d

Thanks Bruno

Regards
Comment 9 Alexandre Julliard 2014-02-07 13:06:07 UTC 
Closing bugs fixed in 1.7.12.
Comment 10 julien.heremans 2017-07-19 11:38:39 UTC 
Hello, 

I know this bug has been reported for a long time but I'm having exactly the same problem right now.

I'm running on Wine 2.0.1 stable, (I see however that the problem was fixed in 1.7.12 version). 

Please, could someone explain how to fix this issue ? For advance, thank you very much!
First Last Prev Next    This bug is not in your last search results.

Privacy Policy
If you have a privacy inquiry regarding this site, please write to [email protected]

Hosted By CodeWeavers