Do you get host resolution error with the curl 7.87.0 and c-ares 1.18.1 or the
host resolution is OK?
If host resolution fails with the new libraries, then I think it all depends on
how network interfaces are picked by c-ares.
If you get resolution error, then maybe, ares_getaddrinfo() picks wrong network
interface somehow?
In your setup, all network interfaces have global IPv6 addresses assigned, but
may be not all of them functional.
Can you try forcing libcurl to use every global IPv6 address for each network
interface and see if it helps?
Thanks,
Dmitry Karpov
-----Original Message-----
From: curl-library <curl-library-boun...@lists.haxx.se> On Behalf Of Peter
Krefting via curl-library
Sent: Thursday, January 19, 2023 3:45 AM
To: curl-library@lists.haxx.se
Cc: Peter Krefting <pe...@softwolves.pp.se>
Subject: [EXTERNAL] IPv6 issues with ares_getaddrinfo()
Hi!
Resending to a more relevant mailing list:
I am upgrading our version of curl and c-ares on an embedded device, and after
upgrading to curl 7.87.0 and c-ares 1.18.1, I found that on a system where IPv6
setup is incomplete (only internal network configured [1]), I am unable to
perform any https requests; IPv4 fall-back does not happen.
Since the issue disappeared while changing c-ares versions, I bisected c-ares
to see if I could find a regression there, rebuilding both libraries at each
point; bisection points me to the commit that changes the version number from
1.15 to 1.16, which lead me to look back at the libcurl code; this code changes
the behaviour of libcurl when it is built against c-ares 1.16 or later:
lib/asyn-ares.c:
#if ARES_VERSION >= 0x011000
/* 1.16.0 or later has ares_getaddrinfo */
#define HAVE_CARES_GETADDRINFO 1
#endif
Removing this, forcing libcurl to use the previous API, fixes all the issues.
This is consistent with my previous finding that building curl
7.87.0 against an older version of c-ares and then upgrading c-ares does not
exhibit the issue.
I am in no way closer to understanding why using this API make requests fail;
how do I best go about debugging this?
[1]
$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP100> mtu 1500 qlen 1000
inet6 2a06:2400:1:0:224:64ff:fe00:1f63/64 scope global dynamic
valid_lft 2591992sec preferred_lft 604792sec
inet6 fe80::224:64ff:fe00:1f63/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP100> mtu 1500 qlen 1000
inet6 2a06:2400:1:1030:224:64ff:fe00:1f64/64 scope global dynamic
valid_lft 2592000sec preferred_lft 604800sec
inet6 fe80::224:64ff:fe00:1f64/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP100> mtu 1500 qlen 1000
inet6 2a06:2400:1:0:224:64ff:fe00:1f65/64 scope global dynamic
valid_lft 2591992sec preferred_lft 604792sec
inet6 fe80::224:64ff:fe00:1f65/64 scope link
valid_lft forever preferred_lft forever
--
\\// Peter - http://www.softwolves.pp.se/
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
