As you suggested I investigated glibc bugs and found that when getaddrinfo uses AF_UNSPEC and looks up an address, it first looks in /etc/hosts and if it finds an IPv4 address it will just return that and never return the IPv6 address. The stop gap fix, before patching glbic, is to just remove any IPv4 entries in /etc/hosts forcing it to do a DNS lookup. Thanks for your help in this matter. Regards, David. On Wed, 27 Oct 2004, Evan Jones wrote:
Welcome to the fun land of IPv6: Dealing with buggy and changing implementations. As far as I am aware, Python's socket module is basically just a wrapper around the operating system. The operating system behaviour changed, not Python's.
On Wed, 2004-10-27 at 09:53, David G Mills wrote:
I've noticed a potential bug and wanted to see if anyone else can replicate it, or has also seen it. When creating a socket with getaddrinfo, with the address family set to AF_UNSPEC and the host set to localhost, the socket binds to IPv4 instead of IPv6. When using the FQD of the machine it binds to IPv6. I've tested the same code on two different machines, and the one running python 2.3.3 works as it should, but the python 2.3.4 doesn't.
What do you expect getaddrinfo to do? Return the IPv6 address first? That is very much up to the implementation. The man page states:
PF_UNSPEC in ai_family specifies any protocol family (either IPv4 or IPv6, for example)
This would imply that returning either an IPv4 or an IPv6 address would be correct. On my system, the following code returns a list of ipv6 addresses:
import socket stuff = socket.getaddrinfo( "evanjones.ca", "http", socket.AF_UNSPEC ) print stuff
[(10, 1, 6, '', ('2002:42a0:8738:1::1', 80, 0, 0)), (10, 1, 6, '', ('2001:470:1f01:ffff::151', 80, 0, 0)), (2, 1, 6, '', ('66.160.135.56', 80))
It does return the IPv6 addresses first, but I'm not sure that is intentional, or if it is pure chance. In your case, if you are looking up the name "localhost," it could be that /etc/hosts on one machine does not map "::1" to the name "localhost." Compare the contents of these files on both machines. My new Debian machine has "ip6-localhost" as "::1." If I change it so "::1" is also localhost, Python returns both addresses.
The one thing that *is* a Python bug is that it does not include "IN6ADDR_LOOPBACK_INIT" or "in6addr_loopback" as constants in the socket module. Hmm... Maybe I should fix this...
Anyone seen this? Can you replicate the error? Any help would be appreciated. Oh yeah, I'm running on FC2 on the 2.3.4 machine and redhat 8 on the 2.3.3 machine.
These machines have different versions of glibc, which could also explain the behaviour change. In fact, there are very recent bug fixes to glibc. For example, this mailing list thread is a fix on top of glibc-2.3.3. My Debian Unstable machine is only running 2.3.2:
http://sources.redhat.com/ml/libc-hacker/2004-09/msg00060.html
On my system, /usr/share/doc/libc6/BUGS states:
[ *] Some of the functions which also handled IPv6 are currently broken. IPv6 and IPv4 lookups occasionally happen when not needed. This happens in getaddrinfo() and getnameinfo(). IPv4 handling of these functions is OK though and there are patches available to fix the IPv6 code as well.
So basically, IPv6 is still very much a "work in progress." I suggest not relying on specific system behaviour.
Hope this helps,
Evan Jones