Bug 697149
Summary: | getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tore Anderson <tore> | ||||||
Component: | glibc | Assignee: | Jeff Law <law> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 15 | CC: | fche, fweimer, gaofeng, gordon.messmer, jakub, mads, orion, psimerda, schwab | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2012-12-16 14:50:29 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Tore Anderson
2011-04-16 07:31:11 UTC
I'm getting hit with this on F15 with a Motorolla DSL modem that returns bogus responses to AAAA requests. Seems like an appropriate fix. Actually, with F15, it is asking for AAAA records even with ipv6 disabled. Orion, I tried to reproduce that using a F15 Beta Live-CD, but could not. If I flush all IPv6 addresses on the system so that the only thing remaining is the loopback one, getaddrinfo() w/AI_ADDRCONFIG set does not look up AAAA records. It does not return them to the caller, nor is it actually requested from the upstream resolver. This is the expected behaviour. (However, if link-local IPv6 addresses are present on the system, AAAA records are looked up as they were in F14. I'm therefore updating the version field of this bug.) Could you explain how, exactly, you disabled IPv6, and how you tested whether or not AAAA lookups were suppressed? Tore Okay, perhaps this is a bug with openssh. It is calling getaddrinfo() with the following hints: {ai_flags = 0, ai_family = 0, ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0, ai_canonname = 0x0, ai_next = 0x0} So, looks like it should set ai_flags to AI_ADDRCONFIG? Created attachment 494740 [details]
getaddrinfo() test program
Orion,
I don't find any mention of AI_ADDRCONFIG in the OpenSSH source code, no, so that would explain it - if AI_ADDRCONFIG isn't set, it will always ask for both A and AAAA records, completely independent of what kind of local addresses are present or not. Perhaps you should submit a bug on the openssh package?
In any case, I'm attaching a simple little test program I wrote for getaddrinfo(). You use it like so:
gcc -o gai-test gai-test.c
./gai-test host1.com host2.com -ac host3.com host4.com
When the "-ac" flag is encountered, AI_ADDRCONFIG is used for all remaining arguments on the command line. So host3 and host4 will be resolved with AI_ADDRCONFIG set, host1 and host2 will not. It also attempts to make a TCP connection to port 80 for all of the returned addresses in the order returned.
Tore
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. *** Bug 505505 has been marked as a duplicate of this bug. *** I installed this patch into rawhide/f17. Any chance we can get this patch into F16? I'm leery of installing the F17 glibc on F16 due to the usrmove changes. I'm planning to revert the change to ignore LINKLOCAL addresses for AI_ADDRCONFIG. The fundamental problem is that change causes problems getaddrinfo ("::1") or any other IPV6 addresses. The code in getaddrinfo properly recognizes that the address is an IPV6 address, but because of the changes to AI_ADDRCONFIG to ignore link-local, getaddrinfo decides the address is useless and drops it on the floor. This causes problems with ssh, apache, heimdal and likely other packages. Given we're dealing with an unofficial interpretation of the standard and the problems it's causing, I'm pulling the patch. Obviously if you can convince the upstream glibc maintainers to make this change, we'll get it via that route, but for now there's not a good reason for Fedora to continue to be the testbed for this change. Jeff, can you elaborate upon the problems you see for ssh/apache/whatnot? It looks as though the patch changes behavior only for link-local (fe80::*) type addresses, not loopback (::1). Once link-local addresses are ignored for AI_ADDRCONFIG (in addition to loopback which are already ignored), getaddrconfig will drop *all* IPV6 addresses on the floor if there aren't configured IPV6 interfaces. So getaddrinfo notes that ::1 is IPV6, but there's no IPV6 interfaces configured and proceeds to drop ::1 on the floor. (In reply to comment #12) > Once link-local addresses are ignored for AI_ADDRCONFIG (in addition to > loopback which are already ignored), getaddrconfig will drop *all* IPV6 > addresses on the floor if there aren't configured IPV6 interfaces. > > So getaddrinfo notes that ::1 is IPV6, but there's no IPV6 interfaces > configured and proceeds to drop ::1 on the floor. Indeed, and that is the expected behaviour of AI_ADDRCONFIG, as far as I understand it. The same thing would hold true even without the patch, if IPv6 is disabled on all the non-loopback interfaces (sysctl -w net/ipv6/conf/eth0/disable_ipv6=1), or the link-local addresses are removed (ip -6 address flush scope local dev eth0). The inverse behaviour is also true for IPv4 - if there are no interfaces with non-link-local IPv4 addresses, getaddrinfo() with AI_ADDRCONFIG will drop 127.0.0.1 and return only ::1. I am interested in learning more about exactly what kind of problems in SSH and Apache this is causing. Do you have a bug ID or other reference? Tore (In reply to comment #10) > The inverse behaviour is also true for IPv4 - if there are no interfaces > with non-link-local IPv4 addresses, getaddrinfo() with AI_ADDRCONFIG will Apologies, thinko here. I meant to say "non-loopback IPv4 addresses". Tore Upstream bug reports: http://sourceware.org/bugzilla/show_bug.cgi?id=12377 http://sourceware.org/bugzilla/show_bug.cgi?id=12398 F15 is dead, another bug report for the same thing is present, will mark duplicate. *** This bug has been marked as a duplicate of bug 505105 *** |