BTW, dirmngr has an option --disable-ipv4.

I see your point.

In any case, an error message that is a bit more specific about what exactly goes wrong would be still be helpful, i.e. it could point out that in this case ipv6 was tried and failed.

In T3331#101967, @werner wrote:

If you don't have a TCP enabled OS, you can use configure --disable-dirmngr.

If IPv4 is enabled but not IPv6, IP stack _is_available and dirmngr should work

And yes, I consider v6 the standard IP implementation theses days. So I would claim that there is no need for a fix. Now, if we have a similar problem with an OS w/o legacy IP support, we should fix that of course.

IPv6 as standard sounds like wishful thinking, in terms of deployment I see 9 machines with IPv4 only for every machine with dual-stack (non-scientific numbers). A failure on IPv4 only only adds to a poor user experience, and for me... people complaining that the pools aren't working

The workaround I've found is to put:

disable-ipv6

in ~/.gnupg/dirmngr.conf. It's a pity that IPv4 isn't supported by default anymore, because some people disable IPv6 on their boxes *precisely* for security reasons---following the same logic that leads one to only install the server software one needs, and open only the needed ports on a firewall, no more.

I agree with @kristianf that dirmngr should be more clever about this sort of failure. The error message could be clearer at least, but the right response is really to skip all IPv4 addresses if the machine has no IPv4 stack, and to skip all IPv6 addresses if the machine has no IPv6 stack.

The question is how to detect whether v4 or v6 is supported. Most systems support both versions but that does not mean that they can actually be used (i.e. due to improper setup or no connectivity). Even the "address family" not supported can be due to a missing kernel module and thus be a transient error message.

A better warning message is of course justified. I need a way to force such a warning for testing, though.

Hello Werner and other participants,

According to https://stackoverflow.com/questions/13441324/ipv6-connectivity-test-in-c Microsoft does a connection test to an IPv4-only box and another one to an IPv6-only box in order to determine connectivity. I suspect such a method wouldn't be much appreciated for GnuPG...

OTOH, https://stackoverflow.com/questions/28097823/how-to-test-from-userspace-if-the-kernel-supports-ipv6 mentions the existence of /proc/net/if_inet6. I can say that on my Linux systems where IPv6 is disabled with ipv6.disable=1 on the kernel command line, this file doesn't exist. So maybe this could be used for Linux, at least?

Note that I don't see any /proc/net/if_inet4 either, although I do have IPv4 connectivity.

Just posting this in case this can help improve out-of-the-box user experience, otherwise the workaround I mentioned above is enough for my needs.

Thanks!

This can easily be solved by adding two more cases to handle_send_request_error(): for GPG_ERR_EADDRNOTAVAIL (that's IPv6 disabled via procfs) and GPG_ERR_EAFNOSUPPORT (that's missing kernel support). Normally I'd submit a patch but I don't care enough to jump through all the hoops just to get two-line change in.

The patch is available in our downstream bugtracker as attachment to https://bugs.gentoo.org/646194