clone 500558 -1
reassign -1 manpages-dev
retitle -1 manpages-dev: getaddrinfo(3): documentation doesn't match
specifications
reassign 500558 libapr1
retitle 500558 libapr1: can't bind to 127.0.0.1 without IPv4 address
tag 500558 + upstream
thanks
On Fri, Feb 17, 2012 at 10:46:09PM +0000, Jean-Michel Vourgère wrote:
> reassign 500558 libapr1
> tags 500558 + upstream
> thanks
>
> I traced back that problem to a call in libapr1, in call_resolver()
> getaddrinfo("127.0.0.1", NULL, &hints, ...) that returns -9
> because hints contains AI_ADDRCONFIG
>
> Without that hint, it works.
>
> Extract from call_resolver:
> if (family == APR_UNSPEC) {
> /* By default, only look up addresses using address types for
> * which a local interface is configured, i.e. no IPv6 if no
> * IPv6 interfaces configured. */
> hints.ai_flags = AI_ADDRCONFIG;
> }
>
> Documentation from getaddrinfo(3):
> If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses
> are returned in the list pointed to by res only if the local system has
> at least one IPv4 address configured, and IPv6 addresses are only
> returned if the local system has at least one IPv6 address configured.
>
> But obviously, having an IPv6 on eth0, and both an IPv4 and IPv6 in lo, is not
> enough to enable IPv4 resolution.
>
The manpage doesn't match the RFC3493 which explicitly exclude the loopback
addresses:
If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system,
and IPv6 addresses shall be returned only if an IPv6 address is
configured on the local system. The loopback address is not
considered for this case as valid as a configured address.
This makes sense, given that a system almost always have both IPv4 and
IPv6 loopback addresses. If loopback adresses were taken into account,
it would make the AI_ADDRCONFIG flag useless.
For me the problem is in call_resolver, which actually should not use
the AI_ADDRCONFIG flag. To know to which addresses to bind to, it should
use the AI_PASSIVE flag instead.
I am therefore cloning this bug to manpages-dev so that the
documentation can be updated, and reassigning the original bug to
libapr1 as the bug has to be fixed there.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
