Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
IPv6 issues with ares_getaddrinfo()
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Peter Krefting via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 19 Jan 2023 12:44:59 +0100 (CET)
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
Date: Thu, 19 Jan 2023 12:44:59 +0100 (CET)
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.htmlReceived on 2023-01-19