http://bugs.winehq.org/show_bug.cgi?id=31994
Bug #: 31994 Summary: AquadelicGT: Socket error, code=10013 Product: Wine Version: 1.5.15 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock AssignedTo: wine-bugs@winehq.org ReportedBy: starous@volny.cz Classification: Unclassified
Created attachment 42173 --> http://bugs.winehq.org/attachment.cgi?id=42173 Wine log - WINEDEBUG="-all,+winsock"
Hello, I am trying to play AquadelicGT game under wine for long time - the game works fine approx. from version 1.5.8 in single player mode if msxml4.dll is replaced by native Windows DLL (As I wrote in AppDB - http://appdb.winehq.org/objectManager.php?sClass=version&iId=18692 ).
But the game is still not working in multiplayer mode - there is displayed message box "Socket error, code=10013" and game freezes every time when I try to start "Join multiplayer game".
First I thought it can be related to CAP_NET_RAW problem - I tried set this capability to game EXE files - Launcher.exe and Run.exe - but this does not help.
Then I found bug 7929 - it looks similarly like my problem, so I waited for fix of this bug. Bug 7929 was fixed in latest release 1.5.15, so I tried it today - but the problem is still the same.
Wine log with debug setting WINEDEBUG="-all,+winsock" is included in attachment. (Note: The game itself is Run.exe file - but it (probably) cannot be started directly, it is started via Launcher.exe file.)
Best regards, Ales
http://bugs.winehq.org/show_bug.cgi?id=31994
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #1 from Erich Hoover ehoover@mines.edu 2012-10-17 20:42:30 CDT --- (In reply to comment #0) ...
Then I found bug 7929 - it looks similarly like my problem, so I waited for fix of this bug. Bug 7929 was fixed in latest release 1.5.15, so I tried it today
- but the problem is still the same.
Are you running a kernel greater than 3.4rc1 and have IP_UNICAST_IF defined by your distro (you can override this if you compile Wine yourself)?
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #2 from Starous starous@volny.cz 2012-10-18 08:55:18 CDT --- (In reply to comment #1)
(In reply to comment #0) ...
Then I found bug 7929 - it looks similarly like my problem, so I waited for fix of this bug. Bug 7929 was fixed in latest release 1.5.15, so I tried it today
- but the problem is still the same.
Are you running a kernel greater than 3.4rc1 and have IP_UNICAST_IF defined by your distro (you can override this if you compile Wine yourself)?
Hi, no, I am Debian user, so my kernel is much more lower number: 2.6.32. So, it looks like I have no chance, hm?
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #3 from Erich Hoover ehoover@mines.edu 2012-10-18 09:00:40 CDT --- (In reply to comment #2)
(In reply to comment #1)
... Are you running a kernel greater than 3.4rc1 and have IP_UNICAST_IF defined by your distro (you can override this if you compile Wine yourself)?
no, I am Debian user, so my kernel is much more lower number: 2.6.32. So, it looks like I have no chance, hm?
Yeah, you would have to upgrade to a newer kernel - but that assumes that you're affected by the same bug. You should see the following FIXME in the console if it's even possible for you to be affected by Bug #7929: Broadcast packets on interface-bound sockets are not currently supported on this platform, receiving broadcast packets will not work on socket %04lx.
It's also worth noting that the CAP_NET_RAW solution needs to be applied to winepreloader, but applications affected by network permission issues should also report a useful FIXME/ERR in the console so that you know that you need to do this.
http://bugs.winehq.org/show_bug.cgi?id=31994
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #4 from Bruno Jesus 00cpxxx@gmail.com 2012-10-18 09:23:50 CDT --- Can you trigger the issue with this file? http://www.hammerware.cz/aquadelic_bg-setup.exe
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #5 from Starous starous@volny.cz 2012-10-18 10:03:02 CDT --- (In reply to comment #4)
Can you trigger the issue with this file? http://www.hammerware.cz/aquadelic_bg-setup.exe
Hi, I tried it now - there is no such problem.
But - You probably now it, but for sure - it is from one simple reason: There is no network multiplayer mode in this free variant of Aquadelic game. In this free game "multiplayer" mode means: all players are playing at the same time on the same PC with the same keyboard... AFAIK, no network multiplayer mode is possible. I reported the bug which is related to better, non-free game variant named "Aquadelic GT" - in opposite to free variant, there is no "multiplayer" on one PC, but You can play in networked multiplayer mode - each player is playing from its own PC connected into some network. And that is what is not working under Wine... :-(
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #6 from Starous starous@volny.cz 2012-10-18 10:41:42 CDT --- (In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
... Are you running a kernel greater than 3.4rc1 and have IP_UNICAST_IF defined by your distro (you can override this if you compile Wine yourself)?
no, I am Debian user, so my kernel is much more lower number: 2.6.32. So, it looks like I have no chance, hm?
Yeah, you would have to upgrade to a newer kernel - but that assumes that you're affected by the same bug. You should see the following FIXME in the console if it's even possible for you to be affected by Bug #7929: Broadcast packets on interface-bound sockets are not currently supported on this platform, receiving broadcast packets will not work on socket %04lx.
It's also worth noting that the CAP_NET_RAW solution needs to be applied to winepreloader, but applications affected by network permission issues should also report a useful FIXME/ERR in the console so that you know that you need to do this.
Hi Erich, as I see the console, there is no such FIXME text as You wrote:
- When I start the game without any special debug settings, I get only these texts: fixme:font:WineEngAddFontResourceEx Ignoring flags 10
- When I start the game with env WINEDEBUG="-all,+winsock", I see what I send before as attachment.
Should I try some another debug setting?
So, what do You think - is it related to Bug #7929? In this case I will wait for new version of Debian - I hope it will have sufficient kernel version (at least in backoprts repository).
Or could it be some another problem?
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #7 from Erich Hoover ehoover@mines.edu 2012-10-18 10:48:11 CDT --- (In reply to comment #6)
... So, what do You think - is it related to Bug #7929? In this case I will wait for new version of Debian - I hope it will have sufficient kernel version (at least in backoprts repository).
No, in that case then this is, to my knowledge, a previously undocumented problem.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #8 from Erich Hoover ehoover@mines.edu 2012-10-18 13:37:57 CDT --- Just out of curiousity... You don't happen to have a really aggressive firewall setup, do you? Error 10013 corresponds to WSAEACCESS, which usually indicates a permissions problem.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #9 from Starous starous@volny.cz 2012-10-18 15:55:50 CDT --- (In reply to comment #8)
Just out of curiousity... You don't happen to have a really aggressive firewall setup, do you? Error 10013 corresponds to WSAEACCESS, which usually indicates a permissions problem.
No, AFAIK I don't use any firewall and I have default iptables setting. When I start e.g. Wine iexplore.exe, it works fine.
But, if it may be important, I have two network cards, from some historical reasons. First one (eth0) has fixed IP address and it is connected into home network, second card (eth1) is connected into internet (via router) and it is configured via Network Manager and DHCP. There is NO routing between these cards (e.g. for internet sharing etc.). Additionally there is also some network interface named pan0 - I don't know exactly what it is, maybe it is some virtual interface of Oracle VirtualBox (or maybe of N2N). This "card" has no IP address.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #10 from Starous starous@volny.cz 2012-10-20 18:17:29 CDT --- (In reply to comment #9)
(In reply to comment #8)
Just out of curiousity... You don't happen to have a really aggressive firewall setup, do you? Error 10013 corresponds to WSAEACCESS, which usually indicates a permissions problem.
No, AFAIK I don't use any firewall and I have default iptables setting. When I start e.g. Wine iexplore.exe, it works fine.
But, if it may be important, I have two network cards, from some historical reasons. First one (eth0) has fixed IP address and it is connected into home network, second card (eth1) is connected into internet (via router) and it is configured via Network Manager and DHCP. There is NO routing between these cards (e.g. for internet sharing etc.). Additionally there is also some network interface named pan0 - I don't know exactly what it is, maybe it is some virtual interface of Oracle VirtualBox (or maybe of N2N). This "card" has no IP address.
Hi Erich, could You tell me some advice(s) how can I do some more detailed tracing inside WS2_sendto function to check exactly where and why it set WSAEACCESS error? E.g. where could be useful to add some more TRACE into winsock code and which information there are important etc... (I have some C language knowledges but I have no idea about (win)sockets...)
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #11 from Bruno Jesus 00cpxxx@gmail.com 2012-10-21 08:00:28 CDT --- (In reply to comment #10)
could You tell me some advice(s) how can I do some more detailed tracing inside WS2_sendto function to check exactly where and why it set WSAEACCESS error? E.g. where could be useful to add some more TRACE into winsock code and which information there are important etc... (I have some C language knowledges but I have no idea about (win)sockets...)
I guess that the application is sending a broadcast packet to 255.255.255.255 which behaves differently from windows, in linux it does not work and return the EPERM error. You can dump the "const struct WS_sockaddr *to" parameter from WS2_sendto using the helper function *debugstr_sockaddr to check that.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #12 from Starous starous@volny.cz 2012-10-23 07:06:05 CDT --- (In reply to comment #11)
(In reply to comment #10)
could You tell me some advice(s) how can I do some more detailed tracing inside WS2_sendto function to check exactly where and why it set WSAEACCESS error? E.g. where could be useful to add some more TRACE into winsock code and which information there are important etc... (I have some C language knowledges but I have no idea about (win)sockets...)
I guess that the application is sending a broadcast packet to 255.255.255.255 which behaves differently from windows, in linux it does not work and return the EPERM error. You can dump the "const struct WS_sockaddr *to" parameter from WS2_sendto using the helper function *debugstr_sockaddr to check that.
Hi Bruno,
THX for advice, You are right, it looks like that: ... trace:winsock:WS2_sendto *to={ family AF_INET, address 192.168.128.255, port 55303 } ...
I expect similar "bug" like that in lot of games which have some network multiplayer mode(s) - and probably not only in games but also in some "serious" programs, so there is maybe logical question:
Did somebody of WineHQ development team think about some workaround? - How to handle this socket differencies Windows and Linux? Or is this problem too game/program-specific and is it not possible to solve it generally?
BR
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #13 from Bruno Jesus 00cpxxx@gmail.com 2012-10-23 07:42:13 CDT --- I'm pretty sure this was discussed before but I could not find it. You could try forcing SO_BROADCAST in the socket. Do something like this inside WS2_sendto after "if ( fd == -1 ) return SOCKET_ERROR;"
n=1; setsockopt(fd,SOL_SOCKET,SO_BROADCAST,&n,sizeof(n));
I'm away from linux so I can't create a diff, sorry.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #14 from Starous starous@volny.cz 2012-10-23 08:55:56 CDT --- (In reply to comment #13)
I'm pretty sure this was discussed before but I could not find it. You could try forcing SO_BROADCAST in the socket. Do something like this inside WS2_sendto after "if ( fd == -1 ) return SOCKET_ERROR;"
n=1; setsockopt(fd,SOL_SOCKET,SO_BROADCAST,&n,sizeof(n));
I'm away from linux so I can't create a diff, sorry.
Hi, I tried to do it in this way: { n = WS2_send( fd, wsa );
+ if (n == -1 && errno == EACCES) + { + n = 1; + setsockopt(fd,SOL_SOCKET,SO_BROADCAST,&n,sizeof(n)); + n = WS2_send( fd, wsa ); + } + if (n != -1 || errno != EINTR) break; } if (n == -1 && errno != EAGAIN)
and it works! THX!
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #15 from Erich Hoover ehoover@mines.edu 2012-10-23 09:03:11 CDT --- (In reply to comment #14)
... and it works! THX!
You have got to be joking, Windows will really allow you to send a broadcast packet without a permissions check? This has got to only be when you send interface-specific broadcasts (though that's still ridiculous).
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #16 from Bruno Jesus 00cpxxx@gmail.com 2012-10-23 09:08:52 CDT --- (In reply to comment #15)
You have got to be joking, Windows will really allow you to send a broadcast packet without a permissions check? This has got to only be when you send interface-specific broadcasts (though that's still ridiculous).
Maybe windows checks the destination IP and automagically set SO_BROADCAST and then disables before the function return. I have used UDP broadcast for a long time in VB6 before finding out what was SO_BROADCAST.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #17 from Erich Hoover ehoover@mines.edu 2012-10-23 09:25:15 CDT --- Created attachment 42240 --> http://bugs.winehq.org/attachment.cgi?id=42240 Enable SO_BROADCAST for interface-specific broadcasts
(In reply to comment #16)
... Maybe windows checks the destination IP and automagically set SO_BROADCAST and then disables before the function return. I have used UDP broadcast for a long time in VB6 before finding out what was SO_BROADCAST.
Did you broadcast to 255.255.255.255 or did you have a case like the one here? I was thinking something like that (see attachment), though it could pose problems in a multithreaded environment. I guess you could throw a critical section around it, but that sounds horrible.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #18 from Starous starous@volny.cz 2012-10-23 09:35:05 CDT --- (In reply to comment #16)
(In reply to comment #15)
You have got to be joking, Windows will really allow you to send a broadcast packet without a permissions check? This has got to only be when you send interface-specific broadcasts (though that's still ridiculous).
Maybe windows checks the destination IP and automagically set SO_BROADCAST and then disables before the function return. I have used UDP broadcast for a long time in VB6 before finding out what was SO_BROADCAST.
Only my stupid note: Even I have no relevant knowledges about winsock, I agree with Bruno - from one simple reason: This game runs without problems in many variants of pure Windows (W98, W2k, WXP). So, Windows do probably the thing in the way which Bruno guess.
(My simple patch is only provisional, finally it should to (at least) do something similar like Bruno told above, i.e., it should test if EACCES is related to broadcast packet according to destination IP. Or maybe better: patch should test destination IP address before calling of WS2_send and modify the packet appropriately - like (probably) do Windows...)
BR
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #19 from Erich Hoover ehoover@mines.edu 2012-10-23 09:44:14 CDT --- (In reply to comment #18)
... (My simple patch is only provisional, finally it should to (at least) do something similar like Bruno told above, i.e., it should test if EACCES is related to broadcast packet according to destination IP. Or maybe better: patch should test destination IP address before calling of WS2_send and modify the packet appropriately - like (probably) do Windows...)
Give attachment 42240 a try ;)
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #20 from Starous starous@volny.cz 2012-10-23 09:57:55 CDT --- (In reply to comment #19)
(In reply to comment #18)
... (My simple patch is only provisional, finally it should to (at least) do something similar like Bruno told above, i.e., it should test if EACCES is related to broadcast packet according to destination IP. Or maybe better: patch should test destination IP address before calling of WS2_send and modify the packet appropriately - like (probably) do Windows...)
Give attachment 42240 [details] a try ;)
Done - OK!
( Even I don't know what does mean this part of patch: FIXME("-> SIO_ADDRESS_LIST_CHANGE request: stub\n"); /* FIXME: error and return code depend on whether socket was created * with WSA_FLAG_OVERLAPPED, but there is no easy way to get this */ + overlapped = NULL; /* hack */ break;
- but don't waste time to explain it to me, if it is too complex.. :-) )
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #21 from Erich Hoover ehoover@mines.edu 2012-10-23 10:23:56 CDT --- (In reply to comment #20)
... ( Even I don't know what does mean this part of patch: FIXME("-> SIO_ADDRESS_LIST_CHANGE request: stub\n"); /* FIXME: error and return code depend on whether socket was created * with WSA_FLAG_OVERLAPPED, but there is no easy way to get this */
overlapped = NULL; /* hack */ break;
- but don't waste time to explain it to me, if it is too complex.. :-)
)
That would be a little hack for something else that I forgot to take out before sending you the patch. Without it a small number of programs will loop forever thinking that the list of network interfaces is constantly changing.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #22 from Bruno Jesus 00cpxxx@gmail.com 2012-10-23 10:49:18 CDT --- (In reply to comment #17)
Did you broadcast to 255.255.255.255 or did you have a case like the one here? I was thinking something like that (see attachment), though it could pose problems in a multithreaded environment. I guess you could throw a critical section around it, but that sounds horrible.
You are right, I used the magic 255.255.255.255, using interface specific broadcast does NOT work in windows but also does NOT generate an error while it does in linux.
About the patch, I don't think softwares in general send data to the same socket at the same time so there should be no need for CS. And there is that problem where weird networks may not have the broadcast set to x.x.x.255 but is uncommon.
@Starous
If possible attach a wireshark debug from the game running in windows. Filter "port 55303". Maybe the packet is not even being sent.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #23 from Bruno Jesus 00cpxxx@gmail.com 2012-10-23 10:52:44 CDT --- (In reply to comment #22)>
If possible attach a wireshark debug...
By wireshark debug I mean wireshark packet capture... Menu Capture -> options -> select the interface, set the Capture filter to "port 55303". Let it run and start the game, after testing the game press Capture -> Stop, then File -> Save and attach the pcap file.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #24 from Erich Hoover ehoover@mines.edu 2012-10-23 11:36:04 CDT --- (In reply to comment #22)
... You are right, I used the magic 255.255.255.255, using interface specific broadcast does NOT work in windows but also does NOT generate an error while it does in linux. ...
Interesting, well that would be a much easier fix if that's truly the case - we can just always return success in the case of a broadcast request.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #25 from Bruno Jesus 00cpxxx@gmail.com 2012-10-23 11:44:01 CDT --- (In reply to comment #24)
Interesting, well that would be a much easier fix if that's truly the case - we can just always return success in the case of a broadcast request.
I'll do more tests in windows and wireshark, at least in my computer which has 3 different IP addresses the broadcast is not going out, I'll attach the test sample so others can test then.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #26 from Starous starous@volny.cz 2012-10-23 12:03:30 CDT --- Created attachment 42241 --> http://bugs.winehq.org/attachment.cgi?id=42241 Windows-WireShark-NetworkMultiplayer-JoinGame
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #27 from Starous starous@volny.cz 2012-10-23 12:04:00 CDT --- Created attachment 42242 --> http://bugs.winehq.org/attachment.cgi?id=42242 Windows-WireShark-NetworkMultiplayer-CreateGame
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #28 from Starous starous@volny.cz 2012-10-23 12:06:58 CDT --- (In reply to comment #23)
(In reply to comment #22)>
If possible attach a wireshark debug...
By wireshark debug I mean wireshark packet capture... Menu Capture -> options -> select the interface, set the Capture filter to "port 55303". Let it run and start the game, after testing the game press Capture -> Stop, then File -> Save and attach the pcap file.
Hi, I sent separately two capture files - it looks (if I good understand their content) like the broadcast packet is really sent. BR
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #29 from Erich Hoover ehoover@mines.edu 2012-10-23 12:09:27 CDT --- (In reply to comment #28)
... Hi, I sent separately two capture files - it looks (if I good understand their content) like the broadcast packet is really sent. BR
I would expect that it has to have working packets at some point (or the game wouldn't function), is the "join game" at the point when it fails under Wine or does Wine fail sooner than that?
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #30 from Bruno Jesus 00cpxxx@gmail.com 2012-10-23 12:11:25 CDT --- (In reply to comment #27)
Created attachment 42242 [details] Windows-WireShark-NetworkMultiplayer-CreateGame
Thank you, this proves my tests are wrong and Erich's patch is correct. I'll dig deeper into this issue.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #31 from Starous starous@volny.cz 2012-10-23 12:28:04 CDT --- (In reply to comment #29)
(In reply to comment #28)
... Hi, I sent separately two capture files - it looks (if I good understand their content) like the broadcast packet is really sent. BR
I would expect that it has to have working packets at some point (or the game wouldn't function), is the "join game" at the point when it fails under Wine or does Wine fail sooner than that?
Hi, the "join game" is at the point when the game fails under Wine (if I good understood Your question). The same situation is the "create game" - the game fails under Wine at the point when I have selected options and pressed "Create game". I.e., all things are pointing to this: The game crashes under Wine at the time when the game wants send the broadcast packet. And the broadcast packet should be really sent into network.
Some small additional note: Maybe better term is: the game "freezes", not crashes. I.e., game goes into neverending loop: It displays Windows dialog window with error message and waits. But when I click on the OK button, the message window is displayed again, because game tries to send new broadcast packet etc., and this loop will never finish...
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #32 from Erich Hoover ehoover@mines.edu 2012-10-23 12:29:51 CDT --- (In reply to comment #30)
(In reply to comment #27)
Created attachment 42242 [details] Windows-WireShark-NetworkMultiplayer-CreateGame
Thank you, this proves my tests are wrong and Erich's patch is correct. I'll dig deeper into this issue.
Did you try with an interface-specific broadcast? Maybe that's the only time this happens.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #33 from Erich Hoover ehoover@mines.edu 2012-10-23 12:33:54 CDT --- (In reply to comment #32)
... Did you try with an interface-specific broadcast? Maybe that's the only time this happens.
Looks like old Windows allows interface-specific broadcasts but new Windows does not: http://www.tech-archive.net/Archive/Development/microsoft.public.win32.progr...
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #34 from Bruno Jesus 00cpxxx@gmail.com 2012-10-23 12:34:12 CDT --- (In reply to comment #32)
Did you try with an interface-specific broadcast? Maybe that's the only time this happens.
The vb6 winsock component does not seem to be able to do that or is failing silently. I'll rewrite my tests in C later.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #35 from Starous starous@volny.cz 2012-10-23 12:40:26 CDT --- (In reply to comment #33)
(In reply to comment #32)
... Did you try with an interface-specific broadcast? Maybe that's the only time this happens.
Looks like old Windows allows interface-specific broadcasts but new Windows does not: http://www.tech-archive.net/Archive/Development/microsoft.public.win32.progr...
It could be, I didn't test this game on newer Windows like Vista or W7.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #36 from Starous starous@volny.cz --- Hi, is it some progress there? I tested newest version of this game (downloaded from Desura) on Windows 7 - and it works (without any compatibility settings, without XP-mode etc.). But under Wine I have still the same issue in the multiplayer... I tested it on newest wine release (wine-1.7.8) included in ArchLinux (kernel 3.12.3-1-ARCH).
BR
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #37 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 48375 --> http://bugs.winehq.org/attachment.cgi?id=48375 another patch version
This is just an alternative patch that will accomplish the same goal from Erich's patch. I just tested the game with it and it worked for me. Erich, do you have any objections on your original patch for this? I think I can create some tests to prove it's OK.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #38 from Starous starous@volny.cz --- Hi, just confirmation - I tried Bruno's alternative patch and it works fine also for me. BR
http://bugs.winehq.org/show_bug.cgi?id=31994
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #39 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Bruno Jesus from comment #37)
Created attachment 48375 [details] another patch version
This is just an alternative patch that will accomplish the same goal from Erich's patch. I just tested the game with it and it worked for me. Erich, do you have any objections on your original patch for this? I think I can create some tests to prove it's OK.
Honestly, I forgot about this bug. The solution is kinda hacky, but I don't see a way to make that not be the case. You're certainly going to need to put together a test to convince AJ that this is necessary, but with a test I'm sure it'll go in just fine and get nominated for the "Most Stupid Win32 API Behavior" award ;) You probably need to test INADDR_BROADCAST and non-matching local broadcasts (bound to 192.168.0.1 but broadcast is 10.0.0.255), since it will probably only work for broadcasts that correspond to the interface that the socket is bound to.
As a side note, you should be able to change: if (manual_broadcast && wsa->addr && wsa->addr->sa_family == WS_AF_INET) to just: if (manual_broadcast) since you've simplified the code such that it's no longer doing unnecessary work ;)
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #40 from Erich Hoover erich.e.hoover@gmail.com --- You know, another way to solve this might be to just turn on broadcast packets if the program binds to a specific interface with a UDP socket. AJ might not be a fan of that though.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #41 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Erich Hoover from comment #40)
You know, another way to solve this might be to just turn on broadcast packets if the program binds to a specific interface with a UDP socket. AJ might not be a fan of that though.
Well, the behavior of XP is inconsistent with the rest. Windows XP will do a broadcast if the address is x.x.x.255, other versions will not.
2000/7/2008/8: sendto(255.255.255.255)+SO_BROADCAST=0 does NOT WORK (as expected) sendto(255.255.255.255)+SO_BROADCAST=1 WORKS (as expected) recvfrom() from the last sendto WORKS sendto(x.x.x.255)+SO_BROADCAST=0 does not WORK
XP: sendto(255.255.255.255)+SO_BROADCAST=0 does not WORK (as expected) sendto(255.255.255.255)+SO_BROADCAST=1 WORKS (as expected) recvfrom() from the last sendto does NOT WORK sendto(x.x.x.255)+SO_BROADCAST=0 WORKS -- this is what this bug is about
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #42 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Bruno Jesus from comment #41)
(In reply to Erich Hoover from comment #40)
You know, another way to solve this might be to just turn on broadcast packets if the program binds to a specific interface with a UDP socket. AJ might not be a fan of that though.
Well, the behavior of XP is inconsistent with the rest. Windows XP will do a broadcast if the address is x.x.x.255, other versions will not. ... sendto(x.x.x.255)+SO_BROADCAST=0 WORKS -- this is what this bug is about
Yeah, I understand - after looking at the logs a little more carefully I retract my comment. The app is binding to INADDR_ANY, I was figuring it might be binding to the adapter that corresponds to the x.x.x.255 network card.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #43 from Bruno Jesus 00cpxxx@gmail.com --- I still think your solution is valid, but we will need a if(OS == XP) in this one.
http://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #44 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Bruno Jesus from comment #43)
I still think your solution is valid, but we will need a if(OS == XP) in this one.
AJ usually doesn't like that, but he might make an exception for this since it's such crappy behavior.
https://bugs.winehq.org/show_bug.cgi?id=31994
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|wine-bugs@winehq.org |00cpxxx@gmail.com
--- Comment #45 from Bruno Jesus 00cpxxx@gmail.com --- I'll try to make tests because we already know the solution.
https://bugs.winehq.org/show_bug.cgi?id=31994
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #42240|0 |1 is obsolete| | Attachment #48375|0 |1 is obsolete| |
--- Comment #46 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 51182 --> https://bugs.winehq.org/attachment.cgi?id=51182 patch with tests
The patch works as expected in the most common network configurations, the problem is that despite the tests works in my XP box and many of the testbot machines it is failing on testbot XP and testbot 2008. So I'm stuck now without a way to convince the testbot to work.
https://bugs.winehq.org/show_bug.cgi?id=31994
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|AquadelicGT: Socket error, |AquadelicGT network game |code=10013 |fails to broadcast data | |(sendto needs to send | |packets to broadcast | |address even without | |SO_BROADCAST enabled)
https://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #47 from Starous starous@volny.cz --- (In reply to Bruno Jesus from comment #46)
Created attachment 51182 [details] patch with tests
The patch works as expected in the most common network configurations, the problem is that despite the tests works in my XP box and many of the testbot machines it is failing on testbot XP and testbot 2008. So I'm stuck now without a way to convince the testbot to work.
Hi Bruno, if it helps to you, I can try to test your patch on my machine with AGT installed. But I can do it next week at the earliest, I am too busy this week. BR, Ales
https://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #48 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Starous from comment #47)
Hi Bruno, if it helps to you, I can try to test your patch on my machine with AGT installed. But I can do it next week at the earliest, I am too busy this week. BR, Ales
Hi, Ales. Fortunately the error is well known now, we reproduced it using tests made from the log so for now I don't think there is need to test the game, when the patch is commited I'll ask you.
https://bugs.winehq.org/show_bug.cgi?id=31994
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=31994
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #49 from winetest@luukku.com --- At least the pach still merges cleanly just some offset changes.
patching file dlls/ws2_32/socket.c Hunk #1 succeeded at 2431 (offset 212 lines). Hunk #2 succeeded at 2446 (offset 212 lines). Hunk #3 succeeded at 2514 (offset 212 lines). patching file dlls/ws2_32/tests/sock.c Hunk #1 succeeded at 5133 (offset 356 lines). Hunk #2 succeeded at 5251 (offset 356 lines).
against wine 1.9.23-git.
The bug should contain patch keyword.
https://bugs.winehq.org/show_bug.cgi?id=31994
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, testcase
https://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #50 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Bruno Jesus from comment #48)
... Hi, Ales. Fortunately the error is well known now, we reproduced it using tests made from the log so for now I don't think there is need to test the game, when the patch is commited I'll ask you.
Bruno, did you ever try to get AJ to accept a version of this? If he has some comments on your solution then maybe we can get this fixed.
https://bugs.winehq.org/show_bug.cgi?id=31994
--- Comment #51 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Erich E. Hoover from comment #50)
Bruno, did you ever try to get AJ to accept a version of this? If he has some comments on your solution then maybe we can get this fixed.
Yes, I sent it in December 2015. But Hans Leidekker was concerned with the fact that we are using a fixed address check instead of calculating the correct broadcast address using the netmask. But it would be painfully slow to do that for EVERY UDP packet as we don't know if the address is a broadcast or not (caching the netmask is dangerous as the IP could change too).
https://www.winehq.org/pipermail/wine-devel/2015-December/110868.html
https://bugs.winehq.org/show_bug.cgi?id=31994
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51182|0 |1 is obsolete| |
--- Comment #52 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 56172 --> https://bugs.winehq.org/attachment.cgi?id=56172 latest patch
This is the latest patch which passes our testbot. I believe it is the same I sent to the list last year.
I did not give up on this bug (or any others where I'm copied/assigned), I'm just stuck in real life. The patch is here and if you want to do anything with it feel free to do so ;-)
https://bugs.winehq.org/show_bug.cgi?id=31994
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
-
wine-bugs＠winehq.org