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