public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rick.jones2 at hp dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes Date: Thu, 07 Jul 2011 17:25:00 -0000 [thread overview] Message-ID: <bug-12377-131-9G5O1e0dEl@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-12377-131@http.sourceware.org/bugzilla/> 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.
next prev parent reply other threads:[~2011-07-07 17:25 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-01-08 20:57 [Bug libc/12377] New: " tore at fud dot no 2011-02-11 15:54 ` [Bug libc/12377] " tore at fud dot no 2011-07-06 20:30 ` rick.jones2 at hp dot com 2011-07-07 9:20 ` tore at fud dot no 2011-07-07 17:25 ` rick.jones2 at hp dot com [this message] 2011-07-07 19:37 ` rick.jones2 at hp dot com 2011-07-08 15:17 ` tore at fud dot no 2011-07-08 16:48 ` rick.jones2 at hp dot com 2011-07-09 11:29 ` tore at fud dot no 2011-07-16 5:37 ` nick.jones@network-box.com 2012-02-19 4:23 ` allan at archlinux dot org 2012-02-21 2:06 ` [Bug network/12377] " jsm28 at gcc dot gnu.org 2012-07-27 13:53 ` psimerda at redhat dot com 2012-07-27 14:01 ` psimerda at redhat dot com 2012-07-27 14:07 ` psimerda at redhat dot com 2012-07-27 14:11 ` psimerda at redhat dot com 2012-07-29 8:30 ` psimerda at redhat dot com 2012-07-29 10:41 ` psimerda at redhat dot com 2012-07-31 12:19 ` tore at fud dot no 2012-07-31 13:17 ` psimerda at redhat dot com 2012-07-31 13:34 ` psimerda at redhat dot com 2012-07-31 13:59 ` tore at fud dot no 2012-07-31 15:01 ` psimerda at redhat dot com 2012-07-31 15:51 ` psimerda at redhat dot com 2012-07-31 18:34 ` tore at fud dot no 2012-07-31 19:00 ` tore at fud dot no 2012-07-31 22:22 ` psimerda at redhat dot com 2012-08-01 9:22 ` tore at fud dot no 2012-08-01 23:16 ` orion at cora dot nwra.com 2012-09-22 15:44 ` psimerda at redhat dot com 2012-11-20 23:16 ` [Bug network/12377] AI_ADDRCONFIG option breaks getaddrinfo() resolution for node-local names and addresses (localhost) psimerda at redhat dot com 2012-11-20 23:18 ` [Bug network/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes psimerda at redhat dot com 2012-12-06 7:04 ` gaofeng at cn dot fujitsu.com 2012-12-18 14:33 ` psimerda at redhat dot com 2012-12-18 14:42 ` [Bug network/12377] getaddrinfo() with AI_ADDRCONFIG won't suppress AAAA queries when only IPv6 loopback and link-local addresses are present psimerda at redhat dot com 2013-08-29 12:45 ` [Bug network/12377] getaddrinfo() with AI_ADDRCONFIG won't suppress AAAA DNS " psimerda at redhat dot com 2014-02-16 18:23 ` jackie.rosen at hushmail dot com 2014-05-28 19:46 ` schwab at sourceware dot org 2014-05-28 19:47 ` schwab at sourceware dot org 2014-06-27 12:32 ` fweimer at redhat dot com 2023-09-20 15:12 ` chrysn at fsfe dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-12377-131-9G5O1e0dEl@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).