dirmngr not working with linux kernel parameter ipv6.disable=1
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	iyanmv
	Jun 22 2020, 10:16 AM

Description

Hi,

When disabling IPv6 on boot (see this) with kernel parameter ipv6.disable=1, dirmngr stops working properly.
This is fixed just by adding disable-ipv6 option to ~/.gnupg/dirmngr.conf but it can be hard to debug if the problem is noticed in other applications using gnupg (e.g. Kleopatra showing invalid trust levels on certificates, Kmail not being able to sign emails, etc.).

I guess I would expect dirmngr not to use IPv6 if IPv6 module is disabled. I found this relevant issue T4165 but it looks like it was only fixed for Windows in 2.2.18. It would be nice to implement something similar for GNU/Linux.

I am currently using Archlinux with linux 5.7.4 and GnuPG 2.2.20. But I can replicate this issue in other distros as well.

Details

Version: 2.2.20

Revisions and Commits

rG GnuPG
	rGce793fc2f838 dirmngr: Handle EAFNOSUPPORT at connect_server.
	rG109d16e8f644 dirmngr: Handle EAFNOSUPPORT at connect_server.

Related Objects

Mentioned In: T4817: dirmgr keys.openpgp.org:443 Address family not supported by protocol
T5030: Release GnuPG 2.2.22
Mentioned Here: T4165: Dirmngr: Ipv6 causes network failure if Ipv6 can't be reached

Event Timeline

iyanmv created this task.Jun 22 2020, 10:16 AM

• werner added projects: dirmngr, gnupg (gpg22).Jun 22 2020, 3:20 PM

The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.

Can you characterize the failure when ipv6.disable=1 ? The straightforward failure (connect() fails with EHOSTUNREACH after a few seconds) should presumably be treated the same as if some other host happened to be offline. That should result in dirmngr failing over to the next available address for the configured keyserver, right?

Is there some other failure pattern happening?

Please get log of dirmngr, by putting

log-file /run/user/<YOURNUMBER-LIKE-1000>/dirmngr.log

If it is socket(2) which fails (like EAFNOSUPPORT), it can be handled in connect_server in dirmngr/http.c.
Now, for me, it looks like giving up too early.

I wonder if this is the case. If so, the fix will be portable and having no test connection.

• gniibe claimed this task.Jun 26 2020, 7:06 AM

When I test it on Debian, disabling by,

sysctl net.ipv6.conf.all.disable_ipv6=1

I got an error of connect with EADDRNOTAVAIL (which is strange for me), nevertheless, dirmngr correctly was marking the host as dead.

@gniibe I saw that you didn't understand what I meant by "dirmngr stops working properly" in E663.
Have a look at this post in Archlinux forum.

I will try now to check what I get in the log file. Sorry for the delay.

$ cat /run/user/1000/dirmngr.log

2020-07-11 19:33:44 dirmngr[2305.0] permanently loaded certificates: 140
2020-07-11 19:33:44 dirmngr[2305.0]     runtime cached certificates: 0
2020-07-11 19:33:44 dirmngr[2305.0]            trusted certificates: 140 (139,0,0,1)
2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id CE04B58CBA5B8069AA0D503634B861593BE86F20; update required
2020-07-11 19:39:24 dirmngr[2305.6] number of system provided CAs: 148
2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error connecting to 'http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error retrieving 'http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] crl_fetch via DP failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] command 'ISVALID' failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id 3476EB7C1E02B3BAF954EEE2EFD321F7B8E49D18; update required
2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error connecting to 'http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] error retrieving 'http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl': Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] crl_fetch via DP failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] command 'ISVALID' failed: Address family not supported by protocol
2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id 70F42DB9235EC84DC35D445B3407CABF4324291C; update required
2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol

log file is longer but I don't see anything else relevant.

Thanks for your log.

IIUC, it causes an error at my_sock_new_for_addr by EAFNOSUPPORT (at assuan_socket), which requires better error handling.

I'm going to add relevant error handling at the place.

• gniibe added a commit: rG109d16e8f644: dirmngr: Handle EAFNOSUPPORT at connect_server..Jul 13 2020, 3:11 AM

• gniibe added a commit: rGce793fc2f838: dirmngr: Handle EAFNOSUPPORT at connect_server..Jul 13 2020, 3:13 AM