Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

multiprotocol (v4 and v6) retry logic seems odd #4954

Closed
vixie opened this issue Feb 20, 2020 · 2 comments
Closed

multiprotocol (v4 and v6) retry logic seems odd #4954

vixie opened this issue Feb 20, 2020 · 2 comments
Labels
connecting & proxies

Comments

@vixie
Copy link

vixie commented Feb 20, 2020

I did this

i told libcurl to connect to a dual-homed (ipv4 and ipv6) web site during a time that i had no ipv6 default route, and the web site's ipv4 address was a black hole (SYN went out, nothing came back.)

I expected the following

i expected a timeout after the freebsd kernel's connect() syscall would have transmitted and retransmitted the SYN for about 30 seconds and then gave up.

what i got was a loop of repeated ipv6 no-such-route notifications from libcurl. see attachment.

curl.txt

curl/libcurl version

curl 7.67.0 (amd64-portbld-freebsd12.0) libcurl/7.67.0 OpenSSL/1.1.1d zlib/1.2.11 nghttp2/1.40.0
Release-Date: 2019-11-06
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL TLS-SRP UnixSockets

operating system

FreeBSD fbsd.local 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
@bagder
Copy link
Member

bagder commented Feb 20, 2020

This puzzles me. curl should only try each address once as it iterates over the list of alternatives (with happy eyeballs). In your output it looks it gets stuck in a loop somehow trying the same IPv6 address over and over while it also waits for a response on the IPv4 connect attempt (that will never arrive).

Unfortunately I don't seem to have any good way to reproduce this case in my end so I've mostly been trying to read that output and compare to the source code...

That "Immediate connect fail" output comes from the singleipconnect() function on this source code line:

curl/lib/connect.c

Line 1290 in 1b6cfb9

infof(data, "Immediate connect fail for %s: %s\n",

Any chance you can set a break-point in there somewhere and see if you can figure out where this goes wrong?

@bagder bagder mentioned this issue Mar 12, 2020
Closed
bagder added a commit that referenced this issue Mar 12, 2020
@bagder
connect: happy eyeballs cleanup
65757da 
Make sure each separate index in connn->tempaddr[] is used for a fixed
family (and only that family) during the connection process.

Fixes #5083
Fixes #4954
@bagder bagder mentioned this issue Mar 12, 2020
Closed
@jay
Copy link
Member

jay commented Mar 12, 2020

#5083 (duplicate) has a repro case.

bagder added a commit that referenced this issue Mar 12, 2020
@bagder
connect: happy eyeballs cleanup
2430ef4 
Make sure each separate index in connn->tempaddr[] is used for a fixed
family (and only that family) during the connection process.

Fixes #5083
Fixes #4954
@bagder bagder closed this as completed in dbd16c3 Mar 15, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jun 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
connecting & proxies
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

connect: happy eyeballs cleanup curl/curl
3 participants
@bagder @jay @vixie