dirmgr keys.openpgp.org:443 Address family not supported by protocol
Closed, DuplicatePublic
Actions

Assigned To

None

Authored By

	mssm
	Jan 17 2020, 12:08 PM

Description

While connecting sks server works fine, it fails with the keys.openpgp.org server:

$ cat  /tmp/dirmgr.log 
2020-01-17 11:14:44 dirmngr[8500] listening on socket '/run/user/4728/gnupg/S.dirmngr'
2020-01-17 11:14:44 dirmngr[8501.0] permanently loaded certificates: 143
2020-01-17 11:14:44 dirmngr[8501.0]     runtime cached certificates: 0
2020-01-17 11:14:44 dirmngr[8501.0]            trusted certificates: 143 (142,0,0,1)
2020-01-17 11:14:44 dirmngr[8501.6] handler for fd 6 started
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> # Home: /home/mb/.gnupg
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> # Config: /home/mb/.gnupg/dirmngr.conf
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> OK Dirmngr 2.2.19 at your service
2020-01-17 11:14:44 dirmngr[8501.6] connection from process 8498 (4728:4728)
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- GETINFO version
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> D 2.2.19
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> OK
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- KEYSERVER --clear hkps://keys.openpgp.org
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> OK
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- KEYSERVER
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> S KEYSERVER hkps://keys.openpgp.org
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> OK
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- KS_PUT
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> INQUIRE KEYBLOCK
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- [ 44 20 99 02 33 30 44 04 59 b1 32 06 01 10 00 a8 ...(982 byte(s) skipped) ]
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- [ 44 20 a6 02 b7 5f 27 23 ee 2c 49 60 0e 40 e9 10 ...(982 byte(s) skipped) ]
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- [ 44 20 50 f6 1d 3f 33 fb 25 30 44 25 30 41 dc 1f ...(982 byte(s) skipped) ]
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- [ 44 20 42 d5 85 25 30 41 74 f6 25 32 35 28 f4 65 ...(982 byte(s) skipped) ]
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- [ 44 20 d7 97 70 2b 17 fc 4f 33 d7 a6 12 58 07 04 ...(982 byte(s) skipped) ]
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- [ 44 20 d2 96 d4 b2 12 e1 0f ae 62 d0 d7 70 f3 fc ...(982 byte(s) skipped) ]
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- [ 44 20 86 1b a9 9c 61 fd 01 54 9f 63 68 33 a5 1f ...(571 byte(s) skipped) ]
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- END
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> INQUIRE KEYBLOCK_INFO
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- D pub::4096:1:997E0920CFD3306C:1504733902:1672337035::::::::::%0Auid:::::1514977035::::Mo <.................de>:::::::%0Asig::::997E3320CFD7F06C:1514973335:::::::::::%0Asig::::997E0920CFD3306C:1504733902:::::::::::%0Asig::::99330920CFD7F06C:1504783346:::::::::::%0Auid:::::1514977035::::Mo <....................de>:::::::%0Asig::::997E0330CFD7F06C:1514977035:::::::::::%0Asig::::99733920CFD7F06C:1503385191:::::::::::%0Asub::4096:1:FB7005230B77339A:1504784902:1611053302::::::::::%0Asub::4096:1:9508F7A793326632:1504785334:1613350642::::::::::%0A
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- END
2020-01-17 11:14:44 dirmngr[8501.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 11:14:44 dirmngr[8501.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 11:14:44 dirmngr[8501.6] number of system provided CAs: 142
2020-01-17 11:14:44 dirmngr[8501.6] error creating socket: Address family not supported by protocol
2020-01-17 11:14:44 dirmngr[8501.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol
2020-01-17 11:14:44 dirmngr[8501.6] marking host 'keys.openpgp.org' as dead
2020-01-17 11:14:44 dirmngr[8501.6] host 'keys.openpgp.org' marked as dead
2020-01-17 11:14:44 dirmngr[8501.6] command 'KS_PUT' failed: No keyserver available
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 <- BYE
2020-01-17 11:14:44 dirmngr[8501.6] DBG: chan_6 -> OK closing connection
2020-01-17 11:14:44 dirmngr[8501.6] handler for fd 6 terminated

$ cat ~/.gnupg/dirmngr.conf 
log-file /tmp/dirmgr.log
debug-level guru

$ cat ~/.gnupg/gpg.conf 
#keyserver  hkps://hkps.pool.sks-keyservers.net:443
keyserver hkps://keys.openpgp.org
keyserver-options auto-key-retrieve include-revoked
use-agent
keyid-format 0xlong

Related Objects

Mentioned Here: T4977: dirmngr not working with linux kernel parameter ipv6.disable=1

Event Timeline

mssm created this task.Jan 17 2020, 12:08 PM

The problem is likely that you don't have IPv4 support but keys.openpgp.org resolves only to a v4 address.
You should also use

debug ipc,dns

instead of the guru thing. BTW, use-agent is obsolete.

As far as I know this is a v4 only network. I tried what you said and get this log:

2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- END
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: libdns initialized
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] number of system provided CAs: 142
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] error creating socket: Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] marking host 'keys.openpgp.org' as dead
2020-01-17 15:39:33 dirmngr[18656.6] host 'keys.openpgp.org' marked as dead
2020-01-17 15:39:33 dirmngr[18656.6] command 'KS_PUT' failed: No keyserver available
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- BYE
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> OK closing connection
2020-01-17 15:39:33 dirmngr[18656.6] handler for fd 6 terminated

Try

ping keys.openpgp.org

and if this works

traceroute keys.openpgp.org

but keys.openpgp.org resolves only to a v4 address.

Is that actually the case on your end? keys.openpgp.org does support ipv6 all around.

$ ping keys.openpgp.org -c1
PING keys.openpgp.org (37.218.245.50) 56(84) bytes of data.
64 bytes from 37.218.245.50 (37.218.245.50): icmp_seq=1 ttl=48 time=24.1 ms

--- keys.openpgp.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.069/24.069/24.069/0.000 ms

$ ping keys.openpgp.org -c1 -6
ping: socket: Address family not supported by protocol

that does look like your host can resolve domains for ipv6 addresses, but can't actually connect to them. what does host keys.openpgp.org say? And ip a?

I guess gnupg isn't at fault for the issue itself here. But it sure would be nice if there was better fallback behavior (try ipv4 if ipv6 doesn't work), and if error reporting was more helpful than "gpg: keyserver send failed: General error".

# host keys.openpgp.org
keys.openpgp.org has address 37.218.245.50
keys.openpgp.org has IPv6 address 2a00:c6c0:0:154:1::1
keys.openpgp.org mail is handled by 100 mail.keys.openpgp.org.

# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 10:20:5b:71:ed:64 brd ff:ff:ff:ff:ff:ff
    inet 10.100.216.171/24 brd 10.100.216.255 scope global dynamic noprefixroute eno1
       valid_lft 153887sec preferred_lft 153887sec

@Valodim: I am pretty sure that last week it resolved only to a v4 address; today (and from another network and resolver) I get the same addresses as you.

@mssm: Things look okay at your site but given that you are behind a NAT gateway all kind of things may happen. You may try to use "standard-resolver" in dirmngr.conf. Is your machine able to handle v6? Getting an error right at socket creation indicates that this is not the case. You may add network to the list of --debug options to see details of the network traffic - this may give more useful diagnostics. What OS are you using?

FWIW, I found an open xterm with my query from last week:

$ host -a keys.openpgp.org
Trying "keys.openpgp.org"
; ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22989
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;keys.openpgp.org.              IN      ANY

;; ANSWER SECTION:
keys.openpgp.org.       592     IN      A       37.218.245.50
keys.openpgp.org.       592     IN      RRSIG   A 8 3 3600 20200207112023 20200116112023 27148 keys.openpgp.org.    FDzPeAbxT0JvSZKc6Vabhh8Q2omxY3UVvuFtX9v+aW8F717ZI3T+zV1l 3Vy0xCePqvMqwMmvb/Pk+YgdG/ugUD3IcO1/LpdvL70fx+640UWiC2RS HBDoUWmpu9xgO4Vf0bGIW3Nvla99nZniYG/9iTX1sQcuOfxrzx4FG64N l+I=

Received 226 bytes from 192.168.4.1#53 in 11 ms

Today things are okay again.:

$  host -a keys.openpgp.org
Trying "keys.openpgp.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26151
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;keys.openpgp.org.              IN      ANY

;; ANSWER SECTION:
keys.openpgp.org.       2111    IN      A       37.218.245.50
keys.openpgp.org.       2111    IN      RRSIG   A 8 3 3600 20200210074919 20200119074919 27148 keys.openpgp.org.  Jz4xM2A4qTEyN0NVAR8NKR7wwqH32T4am+Al40IeYBcHIRcO7niqYCww 67AESuZxFkolZJPP4KkdBccr4JIhRYU8V3LN0ZT3FSlgmQf3dPRVLtga hxlEnWrBCeZ89uQbPKXV+vdCsFdPAFZ2O8eReFZEreUbUiiQORPFWxVm 4XM=
keys.openpgp.org.       3033    IN      AAAA    2a00:c6c0:0:154:1::1
keys.openpgp.org.       3033    IN      RRSIG   AAAA 8 3 3600 20200210074919 20200119074919 27148 keys.openpgp.org. fMGQuqUeMJddsyq8dDyBAwG+9fSD3zWjS4jWx9uT5Trhebkb61p0AIJp +CkwC+bqrPUGtjIKGedfNSziCC6l0TSlS/ybD78XQKmFh9GayIri3iH4 pBdaqn+Je4u+WcP5xLtqe+WaodyFg5gIe5J2kurkwyU66XPorcDUJT0y Jmc=

Received 430 bytes from 192.168.4.1#53 in 8 ms

I have added standard-resolver and debug network to the dirmngr.conf, killed the running dirmngr:

dirmngr[13646] listening on socket '/run/user/4728/gnupg/S.dirmngr'
dirmngr[13647.0] permanently loaded certificates: 143
dirmngr[13647.0]     runtime cached certificates: 0
dirmngr[13647.0]            trusted certificates: 143 (142,0,0,1)
dirmngr[13647.6] handler for fd 6 started
dirmngr[13647.6] DBG: chan_6 -> # Home: /home/mb/.gnupg
dirmngr[13647.6] DBG: chan_6 -> # Config: /home/mb/.gnupg/dirmngr.conf
dirmngr[13647.6] DBG: chan_6 -> OK Dirmngr 2.2.19 at your service
dirmngr[13647.6] connection from process 13644 (4728:4728)
dirmngr[13647.6] DBG: chan_6 <- GETINFO version
dirmngr[13647.6] DBG: chan_6 -> D 2.2.19
dirmngr[13647.6] DBG: chan_6 -> OK
dirmngr[13647.6] DBG: chan_6 <- KEYSERVER --clear hkps://keys.openpgp.org
dirmngr[13647.6] DBG: chan_6 -> OK
dirmngr[13647.6] DBG: chan_6 <- KEYSERVER
dirmngr[13647.6] DBG: chan_6 -> S KEYSERVER hkps://keys.openpgp.org
dirmngr[13647.6] DBG: chan_6 -> OK
dirmngr[13647.6] DBG: chan_6 <- KS_PUT
dirmngr[13647.6] DBG: chan_6 -> INQUIRE KEYBLOCK
............................................
dirmngr[13647.6] DBG: chan_6 <- END
dirmngr[13647.6] DBG: chan_6 -> INQUIRE KEYBLOCK_INFO
dirmngr[13647.6] DBG: chan_6 <- D pub::4096:1:.........................................
dirmngr[13647.6] DBG: chan_6 <- END
dirmngr[13647.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
dirmngr[13647.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
dirmngr[13647.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
dirmngr[13647.6] number of system provided CAs: 142
dirmngr[13647.6] DBG: Using TLS library: GNUTLS 3.6.11
dirmngr[13647.6] DBG: http.c:connect_server: trying name='keys.openpgp.org' port=443
dirmngr[13647.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
dirmngr[13647.6] DBG: http.c:1902:socket_new: object 0x00007f71083237a0 for fd 7 created
dirmngr[13647.6] TLS handshake failed: Access was denied (alert 49)
dirmngr[13647.6] error connecting to 'https://keys.openpgp.org:443': Network error
dirmngr[13647.6] marking host 'keys.openpgp.org' as dead
dirmngr[13647.6] host 'keys.openpgp.org' marked as dead
dirmngr[13647.6] command 'KS_PUT' failed: No keyserver available
dirmngr[13647.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
dirmngr[13647.6] DBG: chan_6 <- BYE
dirmngr[13647.6] DBG: chan_6 -> OK closing connection
dirmngr[13647.6] handler for fd 6 terminated

I have built that app-crypt/gnupg-2.2.19 on Gentoo Linux using these USE (compile) flags:

Installed versions:  2.2.19(16:34:54 16.12.2019)(bzip2 ldap nls readline smartcard ssl usb -doc -selinux -tofu -tools -user-socket -wks-server)

I have dev-libs/openssl-1.1.1d-r3 built with

Installed versions:  1.1.1d-r3(0/1.1)^td(16:34:53 26.11.2019)(asm zlib -bindist -rfc3779 -sctp -sslv3 -static-libs -test -tls-heartbeat -vanilla ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32" CPU_FLAGS_X86="sse2" ELIBC="-musl")

I have built net-libs/gnutls-3.6.11.1-r1 with

Installed versions:  3.6.11.1-r1(0/30)^t(16:33:28 16.12.2019)(cxx idn nls openssl seccomp tls-heartbeat -dane -doc -examples -guile -pkcs11 -sslv2 -sslv3 -static-libs -test -test-full -tools -valgrind ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32")

Linkage looks sane:

$ ldd $(type -p dirmngr)
	linux-vdso.so.1 (0x00007ffdbafa5000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f682e31d000)
	libassuan.so.0 => /usr/lib64/libassuan.so.0 (0x00007f682e307000)
	libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007f682e2e4000)
	libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007f682e1c7000)
	libksba.so.8 => /usr/lib64/libksba.so.8 (0x00007f682e18d000)
	libnpth.so.0 => /usr/lib64/libnpth.so.0 (0x00007f682e187000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f682e162000)
	libgnutls.so.30 => /usr/lib64/libgnutls.so.30 (0x00007f682dfaf000)
	libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f682df63000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f682dd92000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f682e416000)
	libidn2.so.0 => /usr/lib64/libidn2.so.0 (0x00007f682dd71000)
	libunistring.so.2 => /usr/lib64/libunistring.so.2 (0x00007f682dbef000)
	libtasn1.so.6 => /usr/lib64/libtasn1.so.6 (0x00007f682dbd7000)
	libnettle.so.7 => /usr/lib64/libnettle.so.7 (0x00007f682db9c000)
	libhogweed.so.5 => /usr/lib64/libhogweed.so.5 (0x00007f682db62000)
	libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f682dae8000)
	liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f682dad6000)
	libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f682da46000)
	libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f682d78b000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f682d771000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f682d76b000)

$ host -a keys.openpgp.org
Trying "keys.openpgp.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42837
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;keys.openpgp.org.		IN	ANY

;; ANSWER SECTION:
keys.openpgp.org.	3128	IN	A	37.218.245.50
keys.openpgp.org.	21128	IN	NS	ns-cloud-a1.googledomains.com.
keys.openpgp.org.	21128	IN	NS	ns-cloud-a2.googledomains.com.
keys.openpgp.org.	21128	IN	NS	ns-cloud-a3.googledomains.com.
keys.openpgp.org.	21128	IN	NS	ns-cloud-a4.googledomains.com.
keys.openpgp.org.	21128	IN	SOA	ns-cloud-a1.googledomains.com. cloud-dns-hostmaster.google.com. 7 21600 3600 259200 300
keys.openpgp.org.	3128	IN	MX	100 mail.keys.openpgp.org.
keys.openpgp.org.	3128	IN	TXT	"v=spf1 mx ~all"
keys.openpgp.org.	3128	IN	AAAA	2a00:c6c0:0:154:1::1
keys.openpgp.org.	299	IN	CDS	14555 8 2 F7B4A72B3F6EE38ABC9F3A30C94080A5105DF5FFD923C980447F45E3 9959F4D3
keys.openpgp.org.	3128	IN	CAA	0 iodef "mailto:admin@keys.openpgp.org"
keys.openpgp.org.	3128	IN	CAA	0 issue "letsencrypt.org"
keys.openpgp.org.	3128	IN	CAA	0 issuewild ";"

;; ADDITIONAL SECTION:
ns-cloud-a1.googledomains.com. 9851 IN	A	216.239.32.106
ns-cloud-a4.googledomains.com. 8290 IN	A	216.239.38.106

Received 497 bytes from 10.190.225.1#53 in 159 ms

this looks to me like a problem with the TLS handshake -- it looks like this is a response coming from the TLS stack -- as rfc 8446 says, alert 49 is access_denied:

access_denied:  A valid certificate or PSK was received, but when
  access control was applied, the sender decided not to proceed with
  negotiation.

can you capture the network traffic during this handshake and post the .pcap file here? or, try setting tls-debug 16 in dirmngr.log, restart dirmngr again, and show the logs?

Could it be that the system installed CAs are not sufficient for the TSL handshake? But then also curl should fail on that host. But curl https://keys.openpgp.org is fine.

With tls-debug 16:

dirmngr[9162.6] DBG: chan_6 <- END
dirmngr[9162.6] DBG: dns: libdns initialized
dirmngr[9162.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
dirmngr[9162.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
dirmngr[9162.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
dirmngr[9162.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/common.c[_gnutls_x509_get_raw_field2]:1575
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/x509.c[gnutls_x509_crt_get_subject_unique_id]:3902
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/x509.c[gnutls_x509_crt_get_issuer_unique_id]:3952
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] number of system provided CAs: 142
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Allocating epoch #0
dirmngr[9162.6] DBG: gnutls:L2: added 6 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list
dirmngr[9162.6] DBG: Using TLS library: GNUTLS 3.6.11
dirmngr[9162.6] DBG: http.c:connect_server: trying name='keys.openpgp.org' port=443
dirmngr[9162.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
dirmngr[9162.6] error creating socket: Address family not supported by protocol
dirmngr[9162.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol
dirmngr[9162.6] DBG: gnutls:L13: BUF[HSK]: Emptied buffer
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Start of epoch cleanup
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: End of epoch cleanup
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Epoch #0 freed
dirmngr[9162.6] marking host 'keys.openpgp.org' as dead
dirmngr[9162.6] host 'keys.openpgp.org' marked as dead
dirmngr[9162.6] command 'KS_PUT' failed: No keyserver available
dirmngr[9162.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
dirmngr[9162.6] DBG: chan_6 <- BYE
dirmngr[9162.6] DBG: chan_6 -> OK closing connection
dirmngr[9162.6] handler for fd 6 terminated

This appears to be a different error than above. here we see:

error creating socket: Address family not supported by protocol
error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol

but above we saw:

DBG: http.c:1902:socket_new: object 0x00007f71083237a0 for fd 7 created
TLS handshake failed: Access was denied (alert 49)
error connecting to 'https://keys.openpgp.org:443': Network error

Given that keys.openpgp.org has both A and AAAA records, i don't understand why we'd see "Address family not supported by protocol" (EAFNOSUPPORT or GPG_ERR_EAFNOSUPPORT), unless you've got no network stack at all (or dirmngr is some constrained (namespaces? apparmor?) to not see any network stack).

Anyway, if you can get back to the network situation that you were in where you were seeing the TLS handshake failure and try again, that would be useful. But as long you are still seeing the EAFNOSUPPORT response, i'd be interested in seeing the output of:

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye

(if you run it right after a failed connection)

Sorry this debugging is so tedious -- it appears to be something to do with your network connection at least, and that's not something i can replicate easily.

Right after the failed connection I see:

$ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S #   0   4 d keys.openpgp.org (37.218.245.50)  (5s)
OK

ok, that's deeply weird. i'm assuming that this machine has IPv4 connectivity. I have no idea why dirmngr would be returning EAFNOSUPPORT in that case.

Can you perhaps launch dirmngr, attach strace to it, and then do some innocuous query, and post the strace log?

That would look something like:

in terminal A:

dirmngr_pid=$(gpg-connect-agent --dirmngr 'getinfo pid' /bye | awk '/^D/{ print $2}')
strace -p $dirmngr_pid -f -o dirmngr.strace

in terminal B, after having set $FINGERPRINT to the fingerprint of some OpenPGP certificate you have locally:

gpg --send-keys $FINGERPRINT

When the command in terminal B completes, hit ctrl-C in terminal A. Your strace output is in dirmngr.strace.

(if you don't want to publish the full strace output here because you're concerned it might leak some information about your machine or your network, but you're ok sharing it with me personally, you can send it to me privately by e-mail, encrypted to the OpenPGP certificate with fingerprint C4BC2DDB38CCE96485EBE9C2F20691179038E5C6, and sent to one of the e-mail addresses associated with that certificate. please make a note here if you do that)

In T4817#132207, @dkg wrote:

(if you don't want to publish the full strace output here because you're concerned it might leak some information about your machine or your network, but you're ok sharing it with me personally, you can send it to me privately by e-mail, encrypted to the OpenPGP certificate with fingerprint C4BC2DDB38CCE96485EBE9C2F20691179038E5C6, and sent to one of the e-mail addresses associated with that certificate. please make a note here if you do that)

Did you receive my encrypted strace dump? Have you found anything useful to debug there?

• werner triaged this task as Normal priority.Feb 3 2020, 12:09 PM

In T4977: dirmngr not working with linux kernel parameter ipv6.disable=1, EAFNOSUPPORT fix was applied in 2.2.22.
I think that original problem in this report is fixed.
Please test with 2.2.22.

Because the original problem of EAFNOSUPPORT has been fixed, I am going to close this bug.

If you still have an issue for TLS handshake problem, please open new report with relevant title.

• gniibe closed this task as a duplicate of T4977: dirmngr not working with linux kernel parameter ipv6.disable=1.Nov 26 2020, 7:15 AM

dirmgr keys.openpgp.org:443 Address family not supported by protocolClosed, DuplicatePublicActions

Description

Related Objects

Event Timeline

dirmgr keys.openpgp.org:443 Address family not supported by protocol
Closed, DuplicatePublic
Actions