[gnutls-devel] GnuTLS | Testsuite error - listening on IPv6, connecting to IPv4 (#1007)

[Development of GNU's TLS library]

Andreas Metzler commented:


Julien Cristau and Adrian Bunk have shed some light on this in [https://bugs.debian.org/962218](https://bugs.debian.org/962218)

The respective buildd has IPv6 connectivity, the IPv4 loopback is still present, though:
~~~
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 2a02:16a8:dc41:100::240  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::216:37ff:fed2:16f0  prefixlen 64  scopeid 0x20<link>
        ether 00:16:37:d2:16:f0  txqueuelen 1000  (Ethernet)
[...]
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
~~~
However with this setup gnutls-serv only listens on the IPv6 interface:

Adrian:
> The conova buildds are IPv6-only, see #[962019](https://bugs.debian.org/962019) for a similar problem in perl.

and in later message
> The usage of AI_ADDRCONFIG in src/serv.c:listen_socket() looks similar to the problem described in the perl bug.

Julien:
> And indeed gnutls-serv seems to call getaddrinfo with node == NULL and
> hints.ai_flags == AI_PASSIVE|AI_ADDRCONFIG, to figure out what address
> to listen on.  If the host has no non-local ipv4 address, that
> getaddrinfo call returns :: but not 0.0.0.0; and then the test hardcodes
> 127.0.0.1 as the address for gnutls-cli to connect to, and sadness
> ensues.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1007#note_356288765
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200605/b41ecdb8/attachment.html>