http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #82 from Starous starous@volny.cz 2012-10-28 05:49:32 CDT --- (In reply to comment #73)
It's weird that the game creates the socket and closes it without doing anything, try a +relay,+tid and check what it's doing from the socket creation until the closure. Add a trace in WS_getsockopt, case WS_SO_RCVBUF to print the value that is being returned in optval (it should be a %d, needs cast) because relay will only get the function return, this is after line 2622.
I have some ideas, maybe wrong/stupid:
1. GetAdaptersAddresses: It (maybe) looks like the game stops preparing of network multiplayer immediately after calling of GetAdaptersAddresses.
AFAIK, all the games are little bit older, so maybe they expect some exact (or maximal) size of IP_ADAPTER_ADDRESSES structure. As I saw on MS page http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058%28v=vs.85%2..., there are different sizes of IP_ADAPTER_ADDRESSES structure depending of Windows version. And, if I understand source code properly, Wine returns always the same structure, independent of windows version slected in WineCfg.
Additionally, I didn't see the last member (PIP_ADAPTER_DNS_SUFFIX FirstDnsSuffix; - according to link above) in IP_ADAPTER_ADDRESSES structure in iptypes.h.
2. Again GetAdaptersAddresses: There is one more interesting thing on this page: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365915%28v=vs.85%2... See the Remarks about size of IP_ADAPTER_ADDRESSES linked structures - how to determine needed memory size via two subsequent calling of GetAdaptersAddresses. Even if it is discouraged, it looks like DPNET.DLL or the game itself is doing exactly this thing - according to my logs, the first call of GetAdaptersAddresses has parameter AdapterAddresses=NULL.
Maybe there is some similar situation about calling of socket/getsockopt/closesocket?