Bug 216226
| Summary: | yum does not fallback to IPv4 when IPv6 connect times out | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vladimir Kotal <vlada> |
| Component: | python | Assignee: | Mihai Ibanescu <mihai.ibanescu> |
| Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6 | CC: | katzj |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-11-27 22:11:54 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: | |||
|
Description
Vladimir Kotal
2006-11-17 21:39:44 UTC
try doing the same test as with wget but using: /usr/bin/urlgrabber I think this is a lower level problem in python. thanks, urlgrabber seems to exhibit the same behavior.
I have checked that client asks for both AAAA and A DNS records and got both
answers. Then it tries to connect to IPv6 first and if TCP connect fails it
tries IPv4. The number of attempts was cca 18 for each address family.
The problem in my case is that IPv6 TCP connect *was* successfull but server did
not respond with data for some reason. This can be seen in the above output.
('HTTP request sent' is executed only after successful TCP connect) After yums
patience is over it will not try IPv4.
I'm going to reassign this to python b/c I _think_ that's where the problem is. The problem is that there's no way for python to "know" that you want to fallback to IPv4 AFAIK. If you want to use ipv4 vs ipv6 for a specific site with both addresses, you need to set up appropriate rules in /etc/gai.conf (see man gai.conf) While this is true that this is not a bug, reordering AF_INET/AF_INET6 addrinfo entries in getaddrinfo(3) will not provide any sort of fallback in this case - this is just a crude way how to get around this problem for a specific address. Possible solution would be to build more network logic into the application (if TCP connect to AAAA DNS record fails/times-out try TCP connect to A record) but that approach has obvious drawbacks. |