So whenever I specify --interface 18.104.22.168 cURL tries to connect to the destination address from an unusable IPv6. Do I understand it correct?
No, I don't think that's even close. The problem with the current local bind code is that it works rather independently of the remote end which creates this weirdo problems with v4 vs v6 or problems with different v6 scopes.
And the related issue #686 has been reported 3 years ago, so I can conclude it won't be fixed. Correct?
It means that the issue has been reported and we know about it but nobody has yet fixed it. It is a bug and we'd like to have it fixed.
I don't think so. I believe this problem you see happens because curl first resolves the host name and tries to connect to it (over both IPv4 and IPv6), and also tries to bind that socket to the address you've asked - without properly caring for IP version mixes.
A proper fix would probably be something like:
if --interface is provided with an IPv4 address, curl should disable trying to use IPv6 completely since it can't bind such a socket to the IPv4 address.
curl: (45) bind failed with errno 22: Invalid argumentoccurs whenever we specify IPv4 from local interface as a source address trying to connect to a site which have both IPv4 and IPv6.
Steps to reproduce
Pick up a domain which resolves both to IPv4 and IPv6:
can be fixed with
Tested with CentOS 7:
curl 7.65.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.65.1-DEV OpenSSL/1.0.2k-fips zlib/1.2.7
Results are the same.
Whenever a source IPv4 is specified cURL should auto add -4 flag, i.e.:
The same with IPv6, whenever a source IPv6 is specified cURL should auto add -6 flag, i.e.
The text was updated successfully, but these errors were encountered: