This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

--- Comment #6 from Tore Anderson <tore at fud dot no> 2011-07-08 15:16:58 UTC ---
(In reply to comment #4)
> > 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()).

The %ifname convention has nothing to do with getaddrinfo(), it's interpreted
by the application. When passing it to getaddrinfo() you'll get this result:

tore@wrath:~$ ./gai-test ""
[         0us] begin gai_and_connect(
[+    99007us] getaddrinfo( failed: Name or service not
[+       18us] socket() failed

Which, on the wire, shows up as:

17:09:57.165199 IP > 26635+ A? (37)
17:09:57.165215 IP > 30258+ AAAA? (37)
17:09:57.185490 IP > 26635 NXDomain
0/1/0 (112)
17:09:57.185929 IP > 30258 NXDomain
0/1/0 (112)                                                                     

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

Probably the Ubuntu guys have done some patching on their own to get around the
problem with unwanted AAAA lookups hitting broken DNS server.

(In reply to comment #5)
> Perhaps there is different behaviour based on OS X version?
> I put my test program into the hands of some OS X users, and on their systems
> where there were only IPv4 and link-scope IPv6 addresses, the setting of
> AI_ADDRCONFIG did not preclude resolving the likes of "::1" or a link-scope IP
> address (so presumably "::1" was not special cased).  One of them is known to
> be running 10.6.8, the other I don't have their revision information.

I don't have a Mac OS X machine handy right now, but it could be that they only
apply AI_ADDRCONFIG logic when looking up names in DNS, and that any address
found in another name service (such as /etc/hosts) will be returned by
getaddrinfo() regardless of AI_ADDRCONFIG. I know for certain that
AI_ADDRCONFIG will suppress AAAA DNS lookups on Mac OS X if there's only
loopback and link-locals present, though.


Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]