* DNS issue when cloning over HTTP and HTTPS
@ 2013-06-17 22:23 LCD 47
2013-06-17 22:45 ` Daniel Stenberg
0 siblings, 1 reply; 3+ messages in thread
From: LCD 47 @ 2013-06-17 22:23 UTC (permalink / raw)
To: git
The following snippet illustrates the problem:
$ uname -srvm
Linux 3.9.5-smp #2 SMP Mon Jun 10 02:54:26 CDT 2013 i686
$ git --version
git version 1.8.3
$ git clone https://github.com/torvalds/linux.git
Cloning into 'linux'...
fatal: unable to access 'https://github.com/torvalds/linux.git/': Could not resolve host: github.com (Could not contact DNS servers)
Of course, DNS is working fine, and GitHub is accessible from my
machine:
$ dig github.com
; <<>> DiG 9.9.2-P2 <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20305
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;github.com.INA
;; ANSWER SECTION:
github.com.212INA204.232.175.90
;; AUTHORITY SECTION:
github.com.79055INNSns1.p16.dynect.net.
github.com.79055INNSns2.p16.dynect.net.
github.com.79055INNSns3.p16.dynect.net.
github.com.79055INNSns4.p16.dynect.net.
;; Query time: 0 msec
;; SERVER: 192.168.7.2#53(192.168.7.2)
;; WHEN: Tue Jun 18 00:46:13 2013
;; MSG SIZE rcvd: 141
$ ping -c 3 github.com
PING github.com (204.232.175.90) 56(84) bytes of data.
64 bytes from github.com (204.232.175.90): icmp_req=1 ttl=52 time=142 ms
64 bytes from github.com (204.232.175.90): icmp_req=2 ttl=52 time=140 ms
64 bytes from github.com (204.232.175.90): icmp_req=3 ttl=52 time=154 ms
--- github.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 140.184/145.555/154.217/6.183 ms
$ nc -v github.com https
github.com [204.232.175.90] 443 (https) open
^C
A packet capture shows what's going on: Git tries to resolve
github.com over LLMNR rather than DNS, and my router responds with
"destination unreachable". 192.168.7.2 is my machine, and 192.168.7.1
is my router:
No. Time Source Destination Length Expert Protocol Info
1 0.000000 192.168.7.2 192.168.7.1 70 LLMNR Standard query 0xbfe4 A github.com
Frame 1: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: IntelCor_94:18:a4 (00:1c:c0:94:18:a4), Dst: 22:4e:7f:5b:02:55 (22:4e:7f:5b:02:55)
Internet Protocol Version 4, Src: 192.168.7.2 (192.168.7.2), Dst: 192.168.7.1 (192.168.7.1)
User Datagram Protocol, Src Port: 55585 (55585), Dst Port: 13568 (13568)
Source port: 55585 (55585)
Destination port: 13568 (13568)
Length: 36
Checksum: 0x8f89 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Link-local Multicast Name Resolution (query)
Transaction ID: 0xbfe4
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
github.com: type A, class IN
Name: github.com
Type: A (Host address)
Class: IN (0x0001)
No. Time Source Destination Length Expert Protocol Info
2 0.000254 192.168.7.1 192.168.7.2 98 ICMP Destination unreachable (Port unreachable)
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: 22:4e:7f:5b:02:55 (22:4e:7f:5b:02:55), Dst: IntelCor_94:18:a4 (00:1c:c0:94:18:a4)
Internet Protocol Version 4, Src: 192.168.7.1 (192.168.7.1), Dst: 192.168.7.2 (192.168.7.2)
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0x8c86 [correct]
Internet Protocol Version 4, Src: 192.168.7.2 (192.168.7.2), Dst: 192.168.7.1 (192.168.7.1)
User Datagram Protocol, Src Port: 55585 (55585), Dst Port: 13568 (13568)
Source port: 55585 (55585)
Destination port: 13568 (13568)
Length: 36
Checksum: 0x9684 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Link-local Multicast Name Resolution (query)
Transaction ID: 0xbfe4
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
github.com: type A, class IN
Name: github.com
Type: A (Host address)
Class: IN (0x0001)
Cloning with the git protocol works as expected.
A search on the net shows people having the same problem more than
an year ago, and the solution there seems to imply that Git can't cope
with async DNS in curl:
http://osdir.com/ml/freebsd-ports-bugs/2012-05/msg00095.html
Any idea?
/lcd
PS: Please CC me on replies, as I'm not subscribed to this list.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: DNS issue when cloning over HTTP and HTTPS
2013-06-17 22:23 DNS issue when cloning over HTTP and HTTPS LCD 47
@ 2013-06-17 22:45 ` Daniel Stenberg
2013-06-17 23:11 ` LCD 47
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Stenberg @ 2013-06-17 22:45 UTC (permalink / raw)
To: LCD 47; +Cc: git
On Tue, 18 Jun 2013, LCD 47 wrote:
> Cloning with the git protocol works as expected.
>
> A search on the net shows people having the same problem more than an year
> ago, and the solution there seems to imply that Git can't cope with async
> DNS in curl:
>
> http://osdir.com/ml/freebsd-ports-bugs/2012-05/msg00095.html
>
> Any idea?
It's not a git problem really. When you build libcurl to use c-ares for asynch
name resolving you unfortunately don't get a really feature complete
replacement for all stuff the stock synch resolver can do and I believe you
(and person from that link from last year) experience that.
The solution for you is to:
a) rebuild libcurl with another resolving backend (there's a synch and
threaded asynch one to choose from)
or
b) fix c-ares to work "properly" in this scenario as well
--
/ daniel.haxx.se
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: DNS issue when cloning over HTTP and HTTPS
2013-06-17 22:45 ` Daniel Stenberg
@ 2013-06-17 23:11 ` LCD 47
0 siblings, 0 replies; 3+ messages in thread
From: LCD 47 @ 2013-06-17 23:11 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
On 18 June 2013, Daniel Stenberg <daniel@haxx.se> wrote:
> On Tue, 18 Jun 2013, LCD 47 wrote:
>
> > Cloning with the git protocol works as expected.
> >
> >A search on the net shows people having the same problem more than an
> >year ago, and the solution there seems to imply that Git can't cope
> >with async DNS in curl:
> >
> >http://osdir.com/ml/freebsd-ports-bugs/2012-05/msg00095.html
> >
> > Any idea?
>
> It's not a git problem really. When you build libcurl to use c-ares
> for asynch name resolving you unfortunately don't get a really feature
> complete replacement for all stuff the stock synch resolver can do and
> I believe you (and person from that link from last year) experience
> that.
>
> The solution for you is to:
>
> a) rebuild libcurl with another resolving backend (there's a synch and
> threaded asynch one to choose from)
>
> or
>
> b) fix c-ares to work "properly" in this scenario as well
Thank you for the quick and very helpful response. I rebuilt curl
with the threaded resolver, then I rebuilt Git, and now cloning over
HTTP works fine. I'll send a bug report to the maintainers of curl and
Git for my Linux distribution then.
/lcd
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-06-17 23:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-17 22:23 DNS issue when cloning over HTTP and HTTPS LCD 47
2013-06-17 22:45 ` Daniel Stenberg
2013-06-17 23:11 ` LCD 47
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).