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 - curl chokes on IPV4-only internet connection
Summary: curl chokes on IPV4-only internet connection
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: curl
Version: 20
Hardware: All
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-14 14:40 UTC by Oliver Henshaw
Modified: 2015-02-17 13:18 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 13:18:09 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
patch to add AI_ADDRCONFIG to threaded resolver (1.19 KB, patch)
2015-01-14 14:40 UTC, Oliver Henshaw 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1187531 0 unspecified CLOSED curl occasionally fails to connect on dual-stacked hosts 2022-05-16 11:32:56 UTC

Internal Links: 1187531

Description Oliver Henshaw 2015-01-14 14:40:03 UTC 
Created attachment 980044 [details]
patch to add AI_ADDRCONFIG to threaded resolver

Description of problem:

Curl fails to resolve hosts on the first attempt. This causes problems for yum and other users of libcurl. The problem seems to be with the DNS resolver on the local router, which does not cope with AAAA DNS queries.

This can be worked around by using the AI_ADDRCONFIG flag in getaddrinfo(3) though see https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG for the complications. Note that AI_ADDRCONFIG has benefits even on correctly-working single-stack network nodes.


How reproducible:

$ curl -v google.com
* Rebuilt URL to: google.com/
* Could not resolve host: google.com
* Closing connection 0
curl: (6) Could not resolve host: google.com

Subsequent invocatios work correctly.

Curl works if either:
- It's compiled with --disable-ipv6
- It's called with --ipv4
- IPV6 connectivity is disabled and curl is patched to use the AI_ADDRCONFIG flag.

Simply patching curl is not enough, because the ethernet interface will always have an IPV6 address, so there will be link-local IPV6 addresses even when there is only IPV4 internet connectivity - see bug #505105.

IPV6 connectivity can be disabled with 'sysctl -w net.ipv6.conf.all.disable_ipv6=1' - see bug #982740 comment #13. Note that it seems that IPV6 sockets can still be created, thus lib/hostip6.c: Curl_ipv6works() will not work for these purposes.


Version-Release number of selected component (if applicable):

curl-7.37.0-11.fc20.local.1.x86_64 [F21 version rebuilt on F20]
glibc-2.18-16.fc20.x86_64
kernel-3.17.7-200.fc20.x86_64
Comment 1 Kamil Dudka 2015-01-14 15:14:42 UTC 
Thanks for the patch!  I will propose it upstream on your behalf.
Comment 2 Kamil Dudka 2015-01-15 10:48:21 UTC 
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).
Comment 3 Oliver Henshaw 2015-01-15 15:52:00 UTC 
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.
Comment 4 Kamil Dudka 2015-01-15 17:00:53 UTC 
(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.
Comment 5 Kamil Dudka 2015-02-17 13:18:09 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.