[stunnel-users] Connection failure on IPv4-only box with IPv6-address in RR DNS record

Michael Weiser michael at weiser.dinsnail.net
Mon Nov 21 13:14:28 CET 2016


Hi Mike,

On Sun, Nov 20, 2016 at 11:33:47PM +0100, MichaƂ Trojnara wrote:

> > But couldn't stunnel just continue with the next IP if s_socket() failed
> > with EAFNOSUPPORT?
> I just changed the code to continue with the next IP for all the errors.
> It also fixes some local bind issues I struggled with.  8-)

Thanks!

> Please try:
> https://www.stunnel.org/downloads/beta/stunnel-5.38b3.tar.gz

My immediate problem is solved: It connects fine now. But it still logs
the message:

2016.11.21 12:55:27 LOG5[ui]: Service [stunnel] accepted connection from 127.0.0.1:57121
2016.11.21 12:55:27 LOG3[ui]: remote socket: Address family not supported by protocol (97)
2016.11.21 12:55:27 LOG5[ui]: s_connect: connected 192.0.2.1:4120
2016.11.21 12:55:27 LOG5[ui]: Service [stunnel] connected remote server from 192.0.2.10:49032

There might be a number of those if the remote machine has multiple IPv6
addresses in DNS. If the message can't easily be suppressed, perhaps the
IP address being tried could be added for clarity?

BTW: I was just looking into getaddrinfo() for another reason yesterday
and found the AI_ADDRCONFIG flag which seems to be meant for this kind
of situation:

"If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses
are returned in the list pointed to by res only if the local system has
at least one IPv4 address configured, and IPv6 addresses are returned
only if the local system has at least one IPv6 address configured.
The loopback address is not considered for this case as valid as a
configured address. This flag is useful on, for example, IPv4-only
systems, to ensure that getaddrinfo() does not return IPv6 socket
addresses that would always fail in connect(2) or bind(2)."

But I see you need to provide your own implementation for legacy
systems, I guess, so just trying and failing is way simpler, of course.
-- 
Thanks,
Michael



More information about the stunnel-users mailing list