From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10056 invoked by alias); 7 Jul 2011 17:25:27 -0000 Received: (qmail 10022 invoked by uid 22791); 7 Jul 2011 17:25:24 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_QL X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jul 2011 17:25:10 +0000 From: "rick.jones2 at hp dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rick.jones2 at hp dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 07 Jul 2011 17:25:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-07/txt/msg00028.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12377 --- Comment #4 from rick jones 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: mtu 16436 > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: 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: 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.