Howdy all,
Doing some testing with PuTTY, I've noticed some strange behavior. I've got windows XP in a VM, and when comparing behavior to Wine, I noticed some inconsistencies with respect to the '0.0.0.0' invalid address.
Windows: Putty -> 0.0.0.0: throws an error "Network error: Cannot assign requested address" ping (in cmd.exe): D:\appinstall>ping 0.0.0.0
Pinging 0.0.0.0 with 32 bytes of data:
Destination specified is invalid. Destination specified is invalid. Destination specified is invalid. Destination specified is invalid.
Ping statistics for 0.0.0.0: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Wine: Putty -> 0.0.0.0 route to localhost, login succeeds (Not sure if it's routing to localhost or 127.0.0.1)
FWIW, Ubuntu: ssh -> 0.0.0.0: routes to localhost, where I've got sshd running, connects fine. ping -> 0.0.0.0 routes to 127.0.0.1, succeeds
Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. It seems that we're simply passing this on to the host os, which is then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as a special case and refuse? Grepping in the source code for 0.0.0.0 only shows a few hits: comctl32 (unrelated), rpcrt4 (appears unrelated) and ws2_32 (but only in the tests, not in the implementation).
FWIW, using Windows ping.exe under Wine:
Pinging 0.0.0.0 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=64 Reply from 127.0.0.1: bytes=32 time<1ms TTL=64 Reply from 127.0.0.1: bytes=32 time<1ms TTL=64 Reply from 127.0.0.1: bytes=32 time<1ms TTL=64
Ping statistics for 0.0.0.0: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
2009/6/9 Austin English austinenglish@gmail.com:
ping (in cmd.exe): D:\appinstall>ping 0.0.0.0
Pinging 0.0.0.0 with 32 bytes of data:
Destination specified is invalid. Destination specified is invalid. Destination specified is invalid. Destination specified is invalid.
Ping statistics for 0.0.0.0: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Wine: Putty -> 0.0.0.0 route to localhost, login succeeds (Not sure if it's routing to localhost or 127.0.0.1)
FWIW, Ubuntu: ssh -> 0.0.0.0: routes to localhost, where I've got sshd running, connects fine. ping -> 0.0.0.0 routes to 127.0.0.1, succeeds
This doesn't look right to me, but it also happens on my Debian box. Looks like that's how Linux works.
Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. It seems that we're simply passing this on to the host os, which is then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as a special case and refuse?
I'm not sure Wine should be a special case if it's not breaking apps.
On Mon, Jun 8, 2009 at 7:14 PM, Ben Kleinshacklein@gmail.com wrote:
Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. It seems that we're simply passing this on to the host os, which is then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as a special case and refuse?
I'm not sure Wine should be a special case if it's not breaking apps.
While that's arguable , Putty can give a demonstratable corner case that has behavior different on Windows than on Wine, and it's entirely likely that there's some other app depending on that behavior that we *don't* know about.
On Mon, Jun 8, 2009 at 11:10 PM, Austin English austinenglish@gmail.comwrote:
...
I'm not sure Wine should be a special case if it's not breaking apps.
While that's arguable , Putty can give a demonstratable corner case that has behavior different on Windows than on Wine, and it's entirely likely that there's some other app depending on that behavior that we *don't* know about.
-- -Austin
0.0.0.0 and broadcast packets cause some problems with the newer Command and Conquer games, but the ticket was closed some time ago. I believe it was decided that since the kernel devs wouldn't change how Linux handles these cases that it would be too much trouble to work around it.
Erich Hoover ehoover@mines.edu
On Tue, Jun 9, 2009 at 12:15 AM, Erich Hooverehoover@mines.edu wrote:
On Mon, Jun 8, 2009 at 11:10 PM, Austin English austinenglish@gmail.com wrote:
...
I'm not sure Wine should be a special case if it's not breaking apps.
While that's arguable , Putty can give a demonstratable corner case that has behavior different on Windows than on Wine, and it's entirely likely that there's some other app depending on that behavior that we *don't* know about.
-- -Austin
0.0.0.0 and broadcast packets cause some problems with the newer Command and Conquer games, but the ticket was closed some time ago. I believe it was decided that since the kernel devs wouldn't change how Linux handles these cases that it would be too much trouble to work around it.
Erich Hoover ehoover@mines.edu
http://bugs.winehq.org/show_bug.cgi?id=7929
On Tuesday 09 June 2009 07:17:58 Austin English wrote:
0.0.0.0 and broadcast packets cause some problems with the newer Command and Conquer games, but the ticket was closed some time ago. I believe it was decided that since the kernel devs wouldn't change how Linux handles these cases that it would be too much trouble to work around it.
Rereading this bug tells me that it's a) not related to 0.0.0.0 being pingable in unix b) due to programmers abusing the api to get their broadcasts to work c) not fixable by us without kernel support d) not going to happen
Cheers, Kai
On Tuesday 09 June 2009 07:10:40 Austin English wrote:
On Mon, Jun 8, 2009 at 7:14 PM, Ben Kleinshacklein@gmail.com wrote:
Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. It seems that we're simply passing this on to the host os, which is then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as a special case and refuse?
I'm not sure Wine should be a special case if it's not breaking apps.
While that's arguable , Putty can give a demonstratable corner case that has behavior different on Windows than on Wine, and it's entirely likely that there's some other app depending on that behavior that we *don't* know about.
There's a couple of cases where windows networking just works different from Unix networking. We could try to fix all of this in user space (some just can't work, like a socket bound to e.g. 192.168.0.23 on windows will still receive broadcast traffic going on on the vpn network with 10.0.0.255). I'm pretty sure there's more weird things going on. Given that you're not actually supposed to ever send anything to 0.0.0.0 anyway, I don't see how this is actually breaking windows apps that'd never expect this to work anyway.
You're welcome to try and get patches about this past Alexandre, but I'd say that you'd be creating loads of special cases without much reason. It was annoying enough having to handle that modern linux distros always resolve the hostname to a loopback address and many windows apps think that gethostbyname(gethostname()) was a good idea to figure out what IP address to bind to when they actually want to bind to INADDR_ANY. (That's 0.0.0.0 btw, and will find you my "gethostname() should not resolve to localhost" hack.)
In any case, unless we find an app that's really broken due to this, we can possibly reconsider. But I'd argue that if you ask your kernel to contact any IP address for you, you shouldn't be surprised if it's lazy and decides that any IP address might just be localhost.
Cheers, Kai
2009/6/9 Kai Blin kai.blin@gmail.com:
It was annoying enough having to handle that modern linux distros always resolve the hostname to a loopback address and many windows apps think that gethostbyname(gethostname()) was a good idea to figure out what IP address to bind to when they actually want to bind to INADDR_ANY. (That's 0.0.0.0 btw, and will find you my "gethostname() should not resolve to localhost" hack.)
Ah, I thought 0.0.0.0 was invalid. This explains a bit.
Only case that I can think of where 0.0.0.0 handling will break apps is in lazy network programming. Consider the psuedo-code: ip_addr = "0.0.0.0" for (each_ip in valid_addresses) if (some_test(each_ip)) ip_addr=each_ip socket=connect_to(ip_addr)
On Windows, this would likely cause a catchable error. On Linux (at least), the socket connection may succeed. I think someone said C&C3 is affected by this inconsistency between Linux and Windows INADDR_ANY handling; this is probably why :P
Until someone demonstrates a real need for this (with appropriate test cases) ...
2009/6/9 Ben Klein shacklein@gmail.com:
Only case that I can think of where 0.0.0.0 handling will break apps is in lazy network programming.
I am shocked, shocked to hear that there might be apps with lazy network programming! ;-p
On Windows, this would likely cause a catchable error. On Linux (at least), the socket connection may succeed. I think someone said C&C3 is affected by this inconsistency between Linux and Windows INADDR_ANY handling; this is probably why :P Until someone demonstrates a real need for this (with appropriate test cases) ...
Apart from the test cases, didn't you just name a real app that needs this?
- d.
2009/6/9 David Gerard dgerard@gmail.com:
2009/6/9 Ben Klein shacklein@gmail.com:
Only case that I can think of where 0.0.0.0 handling will break apps is in lazy network programming.
I am shocked, shocked to hear that there might be apps with lazy network programming! ;-p
I was going to say "extreme laziness" ...
On Windows, this would likely cause a catchable error. On Linux (at least), the socket connection may succeed. I think someone said C&C3 is affected by this inconsistency between Linux and Windows INADDR_ANY handling; this is probably why :P Until someone demonstrates a real need for this (with appropriate test cases) ...
Apart from the test cases, didn't you just name a real app that needs this?
Well, I don't have C&C3, and I'm not going to get it just to prove it expects a broken connection on 0.0.0.0 ;) Test cases are virtually required for this.
On Tuesday 09 June 2009 11:00:25 David Gerard wrote:
On Windows, this would likely cause a catchable error. On Linux (at least), the socket connection may succeed. I think someone said C&C3 is affected by this inconsistency between Linux and Windows INADDR_ANY handling; this is probably why :P Until someone demonstrates a real need for this (with appropriate test cases) ...
Apart from the test cases, didn't you just name a real app that needs this?
I'm pretty sure C&C had other issues. I don't have C&C (3 iirc) myself, so I can't test that. I know that StarCraft is affected by broadcasts on unix being different than broadcasts on win. However, the StarCraft way of doing networking is _very_ braindead (you can tell IP based network gaming was a quick slap-on patch) and is easy to break on windows machines with more than one network interface as well. I figure C&C has similar issues.
Cheers, Kai
FWIW, a user sent me this e-mail:
I was reading your post about wine and 0.0.0.0 and wanted to share a bug a developer recently came across connected with networking, though I was unsure if you would be interested and I am not confident enough to post to bugzilla (I fear the vitamin<g>).
The developer involved is steve gibson - I think you can download his test software that showed a repeatable crash but with info from the discussion in the mailing list with numerous testters apparently using the latest wine, I am hoping a test from him might not be necessary:
http://12078.net/grcnews/article.php?id=3293&group=grc.dns#3293
quote: Calling "GetNetworkParams" with a null buffer size causes it to fill in the size of the buffer it requires. This size should never change from one call to another --- at least with nothing else changing in the system -- since the requested data is relatively fixed at that point.
http://msdn.microsoft.com/en-us/library/aa365968(VS.85).aspx
But both Robin and Mark's logs reveal that the SECOND call to the same function is -- inexplicably -- returning a smaller value. That's not right.
..., what's more, in Robin's posted case, the call back to the function using the smaller allocation that was all if said it needed ... crashes the app! end quote
I suspect they are talking about this <hopefull fingers crossed> http://source.winehq.org/source/dlls/iphlpapi/iphlpapi_main.c#L1263
example of log of cause of suspected cause of crash http://12078.net/grcnews/article.php?id=3286&group=grc.dns#3286
commentary by another programmer http://12078.net/grcnews/article.php?id=3333&group=grc.dns#3333
Steve is quite amenable to getting his software working well in wine, but is limited in his time. Apparently he does not test for wine, but he has used a workaround to get it working.
HTH regards JHB
-- -Austin
On Tuesday 09 June 2009 17:33:32 Austin English wrote:
FWIW, a user sent me this e-mail:
That looks like a bug in iphlpapi, not related to how wine deals with INADDR_ANY as target ip address. Feel free to open a bug about that, but I fail to see how this is related to the current thread,
Cheers, Kai
-
Austin English -
Ben Klein -
David Gerard -
Erich Hoover -
Kai Blin