Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1182168
| Summary: | curl chokes on IPV4-only internet connection | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Oliver Henshaw <oliver.henshaw> | ||||
| Component: | curl | Assignee: | Kamil Dudka <kdudka> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 20 | CC: | kdudka, paul | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-02-17 13:18:09 UTC | Type: | Bug | ||||
| 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
Oliver Henshaw
2015-01-14 14:40:03 UTC
Thanks for the patch! I will propose it upstream on your behalf. I have been searching more info on this topic. Now I do not have the impression that the AI_ADDRCONFIG flag can be safely used as a default any more. If this gets merged in curl, it needs to be optional I guess.
Please have a look at the following resources (among others):
* bug #699576 comment #1
* https://bugzilla.mozilla.org/614526
* https://code.google.com/p/chromium/issues/detail?id=5234
Simply speaking, applications using the AI_ADDRCONFIG need to implement their own workarounds to avoid unintended changes in behavior. Also the implementation of the flag is different on different OSes (and different versions of them).
Yeah, I guess curl would need to special-case localhost(6). Or could move complexity into libcurl by doing IPv4 and IPv6 lookups on two different threads. Neither option seems particularly appealing, but then the alternative is to wait for some clarity to come at the glic/nsswitch level. I'm now coming round to the idea that resolv.conf(5) options are a better workaround for my buggy router - see bug #505105 comment #76. Though it's slightly frustrating that disabling IPv6 connectivity does not function as a workaround. (In reply to Oliver Henshaw from comment #3) > Yeah, I guess curl would need to special-case localhost(6). It does not sound easy considering all configurations curl has to support. > Or could move > complexity into libcurl by doing IPv4 and IPv6 lookups on two different > threads. That would double the network traffic produced by name resolution I guess. > Neither option seems particularly appealing, but then the > alternative is to wait for some clarity to come at the glic/nsswitch level. > > I'm now coming round to the idea that resolv.conf(5) options are a better > workaround for my buggy router - see bug #505105 comment #76. Yes, that sounds like a reasonable workaround at the time being. As there is no solution in upstream (lib)curl, I am closing this out. The actual cause of the issue is a broken network device. Affected users can change the configuration of the system name resolver to work around the issue system-wide.
Note there is a similar bug report about libcurl not being able to connect (despite it is able to resolve the hostname), which is going to be fixed in the near future:
bug #1187531
|