GNOME Bugzilla – Bug 619931
NetworkManager hides local ip by updating /etc/hosts
Last modified: 2010-10-28 18:28:13 UTC
NetworkManager appears to always re-write /etc/hosts such that the machines hostname is associated with 127.0.0.1 masking any IP assignments or DNS lookup results. This breaks the KDE DHCP web proxy automatic detection (WPAD), which needs the machine's IP address in order to construct a DHCPINFORM query. kpac_dhcp_helper which manages the DHCP component of the WPAD tries to use gethostbyname() on the result of a gethostname() to find the local IP address, but with the NetworkManager modification to /etc/hosts it always comes back as 127.0.0.1, leading the DHCP server to ignore the DHCPINFORM query. As far as I can see there is no better way for kpac_dhcp_helper to determine the local IP address. I think it would make more sense for NetworkManager to associate the local hostname with either the IP of the default route's interface or the result of a DNS lookup on the local hostname when it is available.
See also downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=592658
Your local hostname must always be mapped to something. NetworkManager attempts to keep your hostname mapped to 127.0.0.1 if there is no other entry in /etc/hosts that contains your current hostname. If you wish to map your hostname to another IP, you can do that in /etc/hosts and NetworkManager will leave that entry alone and *not* map your hostname to 127.0.0.1. NM will not (at this time) map a valid external (ie, not 'localhost' or 'localhost.localdomain') hostname to your default IP address. If you have a non-localhost hostname, and there is no NM-created entry for your default device's IP address in /etc/hosts, then I suppose NM could add one for your current default device's IP addresses (yes, plural) and not for 127.0.0.1. But I'm also a bit concerned about apps trying to look up your hostname to find the IP address; that's very fragile. In a default Fedora install, your hostname will be "localhost.localdomain" which clearly will *always* map to 127.0.0.1 regardless of what IP address you have, so you're going to fail there anyway. In short, NM can help out here, but for a large number of cases the WAPD discovery will still be broken until kpac_dhcp_helper uses a smarter mechanism to find out the IP address.
commit debb16cfc035802b14bcf4b9a490a47c8c08ef08 Author: Dan Williams <dcbw@redhat.com> Date: Mon Jun 21 21:18:25 2010 -0700 policy: map hostname to current IP address (bgo #619931) Instead of always mapping the current hostname to 127.0.0.1 or whatever the user mapped it to manually, make sure the hostname maps to the default device's IPv4 and IPv6 address if there's a default device. This helps out services that do a lookup on the machine hostname to determine the IP address, which while a broken behavior (since there are too many edge-cases) is pretty wide-spread and thus we should support it.
So looking into this more for other reasons... man gethostbyname: The gethostbyname*() and gethostbyaddr*() functions are obsolete. Applications should use getaddrinfo(3) and getnameinfo(3) instead. doing gethostbyname (gethostname ()) is a pretty busted way of figuring out your local IP address, obviously, since it depends on glibc oddities and on what your /etc/hosts setup really is. Much better way would be to look at the network interfaces available (via ioctls) and then ask for each one's address until you find one you want...