[Bug libc/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes

["rick.jones2 at hp dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12377

--- Comment #4 from rick jones <rick.jones2 at hp dot com> 2011-07-07 17:24:23 UTC ---

> From this it is easy to infer the true purpose of AI_ADDRCONFIG - avoid looking
> up addresses that it is highly unlikely that you can make use of. Loopbacks and
> link-locals are corner cases since they're always present regardless of
> external
> connectivity, and link-locals is even more of a corner-case than loopbacks as
> a name cannot resolve to a usable link-local address (with an interface id).

Isn't that why there is the "%ifname" convention for the "name" one is passing
to getaddrinfo()?  So it can fill-in the desired/required scope?  I have
distinct recollections of using that frequently with netperf when running IPv6
tests using link-local addressing (though with IPv6 addrs as strings passing to
getaddrinfo()).


> That said, I cannot reproduce the behaviour you're seeing on my Fedora 15
> workstation:
> 
> $ ip -6 address list ; ./gai-test -ac localhost
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
>     inet6 ::1/128 scope host 
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>     inet6 fe80::21d:60ff:fe48:f59e/64 scope link 
>        valid_lft forever preferred_lft forever
> [         0us] -ac seen, using AI_ADDRCONFIG from now on
> 
> [         0us] begin gai_and_connect(localhost)
> [+      560us] getaddinfo(localhost) done
> [+       15us] dest = ::1 (AF_INET6)
> [+        8us] about to connect()
> [+       61us] connect() suceeds
> [+       39us] dest = 127.0.0.1 (AF_INET)
> [+        7us] about to connect()
> [+       49us] connect() suceeds
> $ 
> 
> If I remove the link-local address, however, the ::1 isn't returned, as
> expected:
> 
> $ sudo ip -6 address flush dev eth0; ip -6 address list ; ./gai-test -ac
> localhost
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
>     inet6 ::1/128 scope host 
>        valid_lft forever preferred_lft forever
> [         0us] -ac seen, using AI_ADDRCONFIG from now on
> 
> [         0us] begin gai_and_connect(localhost)
> [+      509us] getaddinfo(localhost) done
> [+       13us] dest = 127.0.0.1 (AF_INET)
> [+        8us] about to connect()
> [+       57us] connect() suceeds
> [+       40us] dest = 127.0.0.1 (AF_INET)
> [+        6us] about to connect()
> [+       39us] connect() suceeds
> $ 

My situation under Maverick does seem odd.  Running my test program under gdb I
single-stepped through make_request() and while the "ifam" showed a family of
10 (PF_INET6) on some of the passes through the loop looking at the netlink
returns, it never hit the path that set seen_ipv6 to true.  I pulled the eglibc
sources and lifted __check_pf() and make_request from them, and after a modicum
of massaging to get them to compile on their own, a test program calling those
*did* set seen_ipv6.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.