multiprotocol (v4 and v6) retry logic seems odd

[vixie]

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]

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?

[jay]

#5083 (duplicate) has a repro case.