Briareos wrote:
The Problem: gethostbyname(own_name) always returns 127.0.0.1. ... To me it's logical that you get 127.0.0.1 when pinging your local hostname, but if windows does give the IP of your NIC then wine should do as well - as we want to reach compatibility.
If, on the other hand, you say it's simply bad programming done by the app-developer if he tries to fetch the IP of the NIC that way, I'd say let's still comply to it, because its more likely than having a programmer expecting to get 127.0.0.1 when asking for "localhostname".
My understanding is that hostnames are not really hostnames, but interface names. On Unix, 127.0.0.1 is never normally returned unless you ask for literally "localhost". I suspect Windows behaves like Unix here. So this probably is a valid bug in wine.
(I suspect that the app developer is misguided, because binding to just one interface doesn't work well if you have multiple interfaces, but that's neither here nor there.) - Dan
On Friday 20 April 2007 15:37, Dan Kegel wrote:
Briareos wrote:
The Problem: gethostbyname(own_name) always returns 127.0.0.1. ... To me it's logical that you get 127.0.0.1 when pinging your local hostname, but if windows does give the IP of your NIC then wine should do as well - as we want to reach compatibility.
If, on the other hand, you say it's simply bad programming done by the app-developer if he tries to fetch the IP of the NIC that way, I'd say let's still comply to it, because its more likely than having a programmer expecting to get 127.0.0.1 when asking for "localhostname".
My understanding is that hostnames are not really hostnames, but interface names. On Unix, 127.0.0.1 is never normally returned unless you ask for literally "localhost". I suspect Windows behaves like Unix here. So this probably is a valid bug in wine.
Looking at a simple test that does (pseudocode)
gethostname(name, len); hostent = gethostbyname(name);
Windows will return 127.0.0.1 if there's no valid IP defined and there's no IP that used to be valid either.
Anyhow, it seems that if there is an IP address that's not loopback, that is returned instead. I'm afraid that won't be easy to fix.. :(
(I suspect that the app developer is misguided, because binding to just one interface doesn't work well if you have multiple interfaces, but that's neither here nor there.)
Well, actually the developer of the app in #7929 is misguided because he's using gethostbyname() with winsock 2.2, which MSDN claims is deprecated. Oh well.
Cheers, Kai
Fredag 20 april 2007 17:46, skrev Kai Blin:
On Friday 20 April 2007 15:37, Dan Kegel wrote:
Briareos wrote:
The Problem: gethostbyname(own_name) always returns 127.0.0.1. ... To me it's logical that you get 127.0.0.1 when pinging your local hostname, but if windows does give the IP of your NIC then wine should do as well - as we want to reach compatibility.
If, on the other hand, you say it's simply bad programming done by the app-developer if he tries to fetch the IP of the NIC that way, I'd say let's still comply to it, because its more likely than having a programmer expecting to get 127.0.0.1 when asking for "localhostname".
My understanding is that hostnames are not really hostnames, but interface names. On Unix, 127.0.0.1 is never normally returned unless you ask for literally "localhost". I suspect Windows behaves like Unix here. So this probably is a valid bug in wine.
Looking at a simple test that does (pseudocode)
gethostname(name, len); hostent = gethostbyname(name);
Windows will return 127.0.0.1 if there's no valid IP defined and there's no IP that used to be valid either.
Anyhow, it seems that if there is an IP address that's not loopback, that is returned instead. I'm afraid that won't be easy to fix.. :(
(I suspect that the app developer is misguided, because binding to just one interface doesn't work well if you have multiple interfaces, but that's neither here nor there.)
Well, actually the developer of the app in #7929 is misguided because he's using gethostbyname() with winsock 2.2, which MSDN claims is deprecated. Oh well.
Cheers, Kai
It should be noted that the app in bug #7929 (Command & Conquer 3 Tiberium Wars) does not run networking correctly on Windows when two interfaces are present.
Alexander N. Sørnes
On Friday 20 April 2007 17:59, Alexander Nicolaysen Sørnes wrote:
(I suspect that the app developer is misguided, because binding to just one interface doesn't work well if you have multiple interfaces, but that's neither here nor there.)
Well, actually the developer of the app in #7929 is misguided because he's using gethostbyname() with winsock 2.2, which MSDN claims is deprecated. Oh well.
It should be noted that the app in bug #7929 (Command & Conquer 3 Tiberium Wars) does not run networking correctly on Windows when two interfaces are present.
I'm not really surprised. That's the reason why gethostbyname is deprecated, if I read MSDN correctly. Anyhow, it looks like Windows doesn't return 127.0.0.1 unless it doesn't have any other IP address to return. Programs can't count on which NIC's IP that will be, though.
I'm working on a patch for this, but it might take me a while, I'll be on the SambaXP conference tomorrow through thursday.
Cheers, Kai
Kai Blin schreef:
I'm not really surprised. That's the reason why gethostbyname is deprecated, if I read MSDN correctly. Anyhow, it looks like Windows doesn't return 127.0.0.1 unless it doesn't have any other IP address to return. Programs can't count on which NIC's IP that will be, though.
Worth noting: Ubuntu resolves hostname to 127.0.1.1 by default, might want to check for 127/8 explicitly instead of just 127.0.0.1
Maarten
-
Alexander Nicolaysen Sørnes -
Dan Kegel -
Kai Blin -
Maarten Lankhorst