[Python-Dev] IPv6 bug in 2.3.4?? (original) (raw)

[Python-Dev] IPv6 bug in 2.3.4?? - found the real cause

David G Mills dgm at ecs.soton.ac.uk
Thu Oct 28 16:02:04 CEST 2004

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 AFUNSPEC 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: > PFUNSPEC in aifamily 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.AFUNSPEC ) 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_ _"IN6ADDRLOOPBACKINIT" or "in6addrloopback" 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

More information about the Python-Dev mailing list