Running curl https://sublime.wbond.net/channel.json
in the console tell me, its unreachable:
$ curl https://sublime.wbond.net/channel.json
curl: (7) Failed to connect to sublime.wbond.net port 443: Network is unreachable
But I can download that json from any browser instance.
Weird. How come?
Here more info. I am on Ubuntu 14.04:
$ curl -V
curl 7.37.1 (x86_64-pc-linux-gnu) libcurl/7.37.1 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
It works perfectly fine for me. Does it fail consistently for you? If you add -v you can see which IP address curl gets and tries. I take it you can get other HTTPS pages fine with curl from that computer?
Hmmmm, thanks for the -v hint. I found out that, when I add "-ip4", then it works. Hmmmm ...
That sounds like a potential happy eyeballs bug. It is supposed to try both ipv4 and upv6 and use the one that works first...
is there a way to configure default curl settings? like forcing the linux machine to use ipv4 instead?
well, i do not have an ipv6 connnection between my router and my isp
If curl tries to connect over ipv6, it is because it got an IPv6 address for the given host and IPv6 works on your system. It is then supposed to try both IPv4 and IPv6 (which is what is called "happy eyeballs") and use the one that connects first. You can force ipv4-only with the dedicated option and you can of course put that in your .curlrc file etc or rebuild curl from source with IPv6 knowledge removed.
Those are still just work-arounds, curl should work out these details by itself. For me it is a bit hard to debug though since I've not been able to repeat this problem in my end.
Since I've failed to repeat this and nobody else seems to either, I will close this report again soonish.
I can reproduce this issue. Trying with the URL from the bug report:
Works fine if passing -4
Using sprunge.us instead, where the server sometimes responds fast enough:
Essentially, if curl manages to test and fail all v6 addresses before a v4 address succeeds, it gives up entirely, not waiting for v4 to finish.
Curl was built with
--enable-threaded-resolver --enable-ipv6
.Can you please try with the latest release? I think it may have been fixed by commit
https://github.com/bagder/curl/commit/759d049ae819adc1e913950da4772b5a6163eb79
Thanks for feedback.
I can't really tell. I can't reproduce the original problem anymore, but the verbose output doesn't list any v6 attempts anymore, either, so it might work by chance now, or something else changed. I'll defer to Michael Heuberger.
can i install the latest version simply with apt-get? do not want to compile all that ...
@dominikh: thanks for having tried.
@michael: Since the latest release is very recent, I don't think Ubuntu provides it already (i'm not working with this distro). You have to watch the repos by yourself, find a third-party binary package for your distro... or compile.
Also watch http://curl.haxx.se/download.html (nothing for you currently, i'm afraid).
Can you please try if 7.41.0 has this fixed? We merged at least two happy eyeballs-related fixes there that I suspect may have fixed this problem!
Closing this. We've done numerous happy-eyeballs fixes since this was reported and I believe it is fixed now.
If not, please open a new bug with a recipe on how to repeat it!