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

Bug#500558: Can't listen to 127.0.0.1 if eth0 has IPv6 only



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
aurelien@aurel32.net                 http://www.aurel32.net



Reply to: