[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#573456: libc6: getaddrinfo() equates AF_UNSPEC with AF_INET for passive lockups



On Thu, Mar 11, 2010 at 09:03:58PM +0100, Mats Erik Andersson wrote:
> torsdag den 11 mars 2010 klockan 20:26 skrev Aurelien Jarno detta:
> > On Thu, Mar 11, 2010 at 07:48:26PM +0100, Mats Erik Andersson wrote:
> > > through the answers that getaddrinfo() care to make. The code
> > > is taken from a package I manage and where I am the upstream
> > > author. I have observed the same difference between glibc
> > > and eglibc for other services I am patching for IPv6 in order
> > > to improve the packages for Debian.
> > 
> > This is your interpretation of the AI_PASSIVE code. getaddrinfo() has
> > always returned multiple adresses, *even in Lenny*, and your code is
> > supposed to cycle through all of them. Nothing in the POSIX function
> > says it should return only one entry. This would even be impossible
> > in Squeeze, as the bindv6only=1 is the default, which means it is not
> > possible to bind to both IPv4 and IPv6 with a single socket.
> > 
> 
> Fair enough, that is why IPV6_V6ONLY is used in my example.
> 
> The bad thing is that the return value is independent of
> whether I impose net.ipv6.bind6only=0 or not. A clearly viable
> conclusion is that eglibc prefers to return an IPv4 wildcard,
> whereas glibc preferred to return the IPv6 wildcard first.
> 
> > By the way the getaddrinfo code is identical in glibc and eglibc, 
> > so please stop blaming eglibc.
> > 
> The differences in return order for the address families must therefore
> be sought in some other mechanism. This is useful information.
> 

The order has indeed change somewhere between glibc 2.7 and 2.10, and
now depends on the IP present on your machines. I guess your code has 
to cope with that, as this is now the defaults on all distributions that
have a recent eglibc or glibc (Ubuntu, Fedora, SuSe, ...).

Anyway the order has never been specified, and the one returned by
recent glibc is perfectly valid.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net



Reply to: