http://bugs.winehq.org/show_bug.cgi?id=25377
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #14 from Erich Hoover ehoover@mines.edu 2010-12-04 15:25:03 CST --- It's possible that this is an accumulation of more than one problem, as without WSARecvMsg the application may not even attempt to look for servers. A log with the patch applied might help.
I actually wouldn't be surprised to find that the application uses WSARecvMsg to find the interface necessary to connect to the server and then it performs an interface-specific bind (which would require the rest of the patches on my site). Searching for servers using UDP in an interface-bound manner is not completely uncommon, since it allows you to obtain information that you would not acquire when binding to INADDR_ANY. I know this because I used roughly the same technique when I was working for a private company. At the time I didn't know about WSARecvMsg, so I sent out a broadcast on INADDR_ANY first and then on each interface (just like what is seen in Bug #7929). Anyway, you should be able to detect if this scenario is the case if you run your application like this: --- WINEDEBUG="+winsock" wine APPNAME.EXE 2>&1 | grep WS_bind --- If you see something like the following (where the address is anything except INADDR_ANY, AKA 0.0.0.0) then your application is performing an interface-specific bind and you will need to add the rest of the patches from my site (and this bug would be a duplicate of Bug #7929): --- trace:winsock:WS_bind socket 0284, ptr 0x2cdf11c { family AF_INET, address 192.168.0.188, port 8086 }, length 16 ---