Re: ws2_32: Work around the host name resolving to 127.x.x.x when using that for binding.
On Mon, Apr 14, 2008 at 04:05:23PM +0200, Kai Blin wrote:
Hi Kai, et all,
+static const char magic_loopback_addr[] = {127, 12, 34, 56};
in the past wine used to work quite well with the ip-address configured using the places in the windows registry (msdn or something similar kept an howto for setting the ips in win98 and 2k (and look alikes)). now that wine tries to get its ip from the /etc/hosts (or whereever?) i noticed some problems with hosting games. as msdn keeps firing errors at me i go and ask the list about this.
i always though windows (at least until xp?) is not capable of listening to requests bound to an ip/interface? with the recent changes the games listen to lo0 and will never ever accept anything. i had to change my /etc/hosts now to make it work again; yet it will fail with more than one nic (i have to change /etc/hosts again).
long story short:
- does any windows version at all support the idea behind giving an ip to listen for connections like unix/linux/bsd does?
- and even if: who runs some windows software in wine that needs this features and is not able to fix the problem with the firewall or other restrictions on the unix end?
if no: what would be needed to change the listening to 0.0.0.0 by default? a patch and a test?
On Mon, 14 Apr 2008, Christoph Frick wrote:
On Mon, Apr 14, 2008 at 04:05:23PM +0200, Kai Blin wrote:
Hi Kai, et all,
+static const char magic_loopback_addr[] = {127, 12, 34, 56};
in the past wine used to work quite well with the ip-address configured using the places in the windows registry (msdn or something similar kept an howto for setting the ips in win98 and 2k (and look alikes)). now that wine tries to get its ip from the /etc/hosts (or whereever?) i noticed some problems with hosting games. as msdn keeps firing errors at me i go and ask the list about this.
i always though windows (at least until xp?) is not capable of listening to requests bound to an ip/interface? with the recent changes the games listen to lo0 and will never ever accept anything. i had to change my /etc/hosts now to make it work again; yet it will fail with more than one nic (i have to change /etc/hosts again).
long story short:
- does any windows version at all support the idea behind giving an ip
to listen for connections like unix/linux/bsd does?
- and even if: who runs some windows software in wine that needs this
features and is not able to fix the problem with the firewall or other restrictions on the unix end?
if no: what would be needed to change the listening to 0.0.0.0 by default? a patch and a test?
-- cu
Hi!
All versions of Windows support binding to an IP address - although the (preferred) method used for enumerating interfaces and their IP address varies with version (not that there is a portable way across *NIXes).
Binding to a specific address is the only easy way of detecting which interface an UDP packet was received on since recvfrom() only gives source address, not destination. Listening on 0.0.0.0 would make impossible to tell which interface a packet was received on. Furthermore, a program that explicitely tries to bind to each interface would fail all but the first bind and possibly bail out. Probably many games that use UDP would break.
Regards,
Paul Chitescu
On Monday 14 April 2008 18:42:26 Paul Chitescu wrote:
Binding to a specific address is the only easy way of detecting which interface an UDP packet was received on since recvfrom() only gives source address, not destination. Listening on 0.0.0.0 would make impossible to tell which interface a packet was received on. Furthermore, a program that explicitely tries to bind to each interface would fail all but the first bind and possibly bail out. Probably many games that use UDP would break.
I'm currently trying to fix apps that fail doing the following (which seems to be a popular way among game developers), in pseudo-code.
hostname = gethostname(); hostent = gethostbyname(hostname); sockaddr->sin_addr = hostent->addr; sock = socket(); bind(sock, sockaddr);
Which, as Christoph noted, cause windows apps to bind to loopback addresses, breaking the networking. This only started to happen recently as recently Linux distros started mapping the machine's hostname to a loopback address. I don't think Wine ever used the registry for anything like that.
Cheers, Kai
On Mon, Apr 14, 2008 at 11:04:52PM +0200, Kai Blin wrote:
Binding to a specific address is the only easy way of detecting which interface an UDP packet was received on since recvfrom() only gives source address, not destination. Listening on 0.0.0.0 would make impossible to tell which interface a packet was received on. Furthermore, a program that explicitely tries to bind to each interface would fail all but the first bind and possibly bail out. Probably many games that use UDP would break.
does then windows actually handle also the other way around? like i listen on 127.0.0.1:12345 in windows and i will not be able to connect to 192.168.1.1:12345 on the same machine? i know it is "supported" - but i have the nagging doubt, that it will not work the same way as in unix but wine maps this behaviour as as unix would do it the same way. IANAE...
Which, as Christoph noted, cause windows apps to bind to loopback addresses, breaking the networking. This only started to happen recently as recently Linux distros started mapping the machine's hostname to a loopback address. I don't think Wine ever used the registry for anything like that.
not wine in its guts - the apps. wine now uses the /etc/hosts to determine the ip of the machine and put this informations in the places, where windows keeps them. one of this places was the registry (.../nettrans/tcpip/... or something). some apps use this informations. maybe
On Mon, 14 Apr 2008, Kai Blin wrote:
On Monday 14 April 2008 18:42:26 Paul Chitescu wrote:
Binding to a specific address is the only easy way of detecting which interface an UDP packet was received on since recvfrom() only gives source address, not destination. Listening on 0.0.0.0 would make impossible to tell which interface a packet was received on. Furthermore, a program that explicitely tries to bind to each interface would fail all but the first bind and possibly bail out. Probably many games that use UDP would break.
I'm currently trying to fix apps that fail doing the following (which seems to be a popular way among game developers), in pseudo-code.
hostname = gethostname(); hostent = gethostbyname(hostname); sockaddr->sin_addr = hostent->addr; sock = socket(); bind(sock, sockaddr);
Which, as Christoph noted, cause windows apps to bind to loopback addresses, breaking the networking. This only started to happen recently as recently Linux distros started mapping the machine's hostname to a loopback address. I don't think Wine ever used the registry for anything like that.
Cheers, Kai
-- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
Hi, Kai!
Your patch seems quite safe to me as it checks lots of stuff. I disagreed to Christoph Frick's proposal of always binding to 0.0.0.0
As a security enhancement, what about randomly initializing the last 3 octets of magic_loopback_addr at every run instance? This could help fend off potential attacks targeted at buggy applications running in Wine by sending this special address over some other protocol. A remote attacker can convince a local application to listen on all interfaces including Internet attached ones while thinking it (safely) listens only on loopback.
Regards,
Paul Chitescu
-
Christoph Frick -
Kai Blin -
Paul Chitescu