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

[David G Mills]

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
> 
>