FS#27988 - sketchy interaction with ipv6

Attached to Project: Pacman
Opened by Dave Reisner (falconindy) - Wednesday, 18 January 2012, 22:06 GMT
Last edited by Allan McRae (Allan) - Sunday, 29 June 2014, 07:25 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.1
Due in Version 4.2.0
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

As shown in the post below, some users are seeing odd behavior with curl trying to grab an ipv6 socket when their network stack isn't ipv6 capable.

https://bbs.archlinux.org/viewtopic.php?id=133774

Q's from Dan:
- is there any ipv6 non-link-local address configured?
- are there any ipv6 entries in /etc/resolv.conf?

We also need a better strace which follows children of curl to see what libresolv on each resolution attempt. Additionally, we should see how the curl binary tool behaves on these machines. This isn't anything new, and we've seen reports of this before in wget. I'd rather the solution not be "disable ipv6".

As a corollary, do we want to consider adding some extra knobs to /etc/pacman.conf to tune the downloader? curl has the ability to force ipv4 or ipv6 rather than the default behavior of auto detection. We should also tie in libcurl's CURLOPT_DEBUG{FUNCTION,DATA} to libalpm's debug callback.
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 29 June 2014, 07:25 GMT
Reason for closing:  Upstream
Additional comments about closing:  Assuming fixed with curl-7.34
Comment by Dave Reisner (falconindy) - Saturday, 21 January 2012, 00:50 GMT
Attaching some relevant stack traces comparing what pacman and curl do.

Would love to see routing info (ip -6 r; ip -r) from someone afflicted by this.
   curl.strace (59.4 KiB)
   pacman.strace (154.6 KiB)
Comment by Samuel Vargas (DoctorSamulus) - Sunday, 22 January 2012, 20:33 GMT
I was affected by this bug :\ luckily ionia on #archlinux helped me fix it. I attached the relevant info hopefully this helps. If there is anything else needed just ask.
   curl.strace (77.4 KiB)
   ip -6 r (0 KiB)
   ip a (0.5 KiB)
   pacman.strace (149.7 KiB)
   resolv.conf (0.3 KiB)
Comment by Allan McRae (Allan) - Friday, 04 January 2013, 13:10 GMT
@Dave: I know you are busy, but is there any chance of this being looked at before 4.1?
Comment by Dave Reisner (falconindy) - Friday, 04 January 2013, 13:16 GMT
Can anyone confirm that this is still a problem? I haven't heard any complaints in a while.
Comment by Arun Shivaram (arun) - Wednesday, 16 January 2013, 11:19 GMT
I encountered this problem on a fresh install of arch linux. Pacman version used - Pacman v4.0.3 - libalpm v7.0.3

If ipv6 is enabled, connection time out happens most of the time with sporadic successful connections.

Works properly if
- ipv6 is disabled OR
- domain names are replaced with ip addresses in the mirror list.

I have attached the trace logs for your reference (trimmed the mirror list to few servers, to reduce time)
   curl.strace (61.3 KiB)
   pacman.strace (594.9 KiB)
   ip -6 r (0.2 KiB)
   ip a (0.5 KiB)
   resolv.conf (0.3 KiB)
   mirrorlist (0.5 KiB)
Comment by Dave Reisner (falconindy) - Monday, 18 November 2013, 17:52 GMT
I suspect that this will be "fixed" with curl 7.34.0 which implements happy eyeballs (RFC 6555).

http://tools.ietf.org/html/rfc6555

If anyone wants to try building curl from git and verifying this, feel free. I've still not been able to replicate this.