Page MenuHome GnuPG

Dirmngr: Ipv6 causes network failure if Ipv6 can't be reached
Closed, ResolvedPublic

Description

Analyzing T4163 on linux showed a problem to me. Servers are tried with Ipv6 even though I do not have Ipv6 from my ISP. This causes a failure. It only happens If I use the pool address. It does not happen if I use a direct address.

As a user supporter I find any failure of a keyserver fetch unacceptable, even if the situation resolves itself "probably" on the next call. Dirmngr should at least try the next server in that case.

Here is my test script:

SERVERS="hkps://fks.pgpkeys.eu
hkps://pgpkeys.co.uk
hkps://pgpkeys.eu
hkps://pgpkeys.uk
hkps://hkps.pool.sks-keyservers.net
"

rm -r /tmp/ks-test
for i in {1..100}; do
for server in $SERVERS; do
    datadir=/tmp/ks-test/run-$server-$i
    mkdir -p $datadir
    echo "debug-level guru" >> $datadir/dirmngr.conf
    echo "log-file $datadir/dirmngr.log" >> $datadir/dirmngr.conf
    echo "---------- $datadir ------------"
    gpg --homedir $datadir --keyserver $server --verbose --recv-key \
        94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1 2>&1 | tee $datadir/fetch-log
done
done

Here is a failing dirmngr.log:

2018-10-01 14:25:17 dirmngr[23021] listening on socket '/run/user/1000/gnupg/d.uyonajshktgqc6swgxoux57w/S.dirmngr'
2018-10-01 14:25:17 dirmngr[23022.0] permanently loaded certificates: 152
2018-10-01 14:25:17 dirmngr[23022.0]     runtime cached certificates: 0
2018-10-01 14:25:17 dirmngr[23022.0]            trusted certificates: 152 (151,0,0,1)
2018-10-01 14:25:17 dirmngr[23022.0] failed to open cache dir file '/tmp/ks-test/run-hkps://hkps.pool.sks-keyservers.net-4/crls.d/DIR.txt': No such file or directory
2018-10-01 14:25:17 dirmngr[23022.0] creating directory '/tmp/ks-test/run-hkps://hkps.pool.sks-keyservers.net-4/crls.d'
2018-10-01 14:25:17 dirmngr[23022.0] new cache dir file '/tmp/ks-test/run-hkps://hkps.pool.sks-keyservers.net-4/crls.d/DIR.txt' created
2018-10-01 14:25:17 dirmngr[23022.0] error enabling fast daemon termination: Too many open files
2018-10-01 14:25:17 dirmngr[23022.5] handler for fd 5 started
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> # Home: /tmp/ks-test/run-hkps://hkps.pool.sks-keyservers.net-4
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> # Config: /tmp/ks-test/run-hkps://hkps.pool.sks-keyservers.net-4/dirmngr.conf
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> OK Dirmngr 2.2.10-beta1 at your service
2018-10-01 14:25:17 dirmngr[23022.5] connection from process 23019 (1000:1000)
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 <- GETINFO version
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> D 2.2.10-beta1
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> OK
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 <- KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> OK
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 <- KS_GET -- 0x94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2a01:4f8:190:1150::111]'
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2001:41d0:2:18b::82:0]'
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2001:67c:26b4::99:0]'
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2001:67c:26b4::98:0]'
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '192.146.137.99'
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '192.146.137.98'
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '5.135.174.82'
2018-10-01 14:25:17 dirmngr[23022.5] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '5.9.137.111'
2018-10-01 14:25:17 dirmngr[23022.5] can't connect to '2001:67c:26b4::99:0': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] error connecting to 'https://[2001:67c:26b4::99:0]:443': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] marking host '[2001:67c:26b4::99:0]' as dead
2018-10-01 14:25:17 dirmngr[23022.5] can't connect to '2001:41d0:2:18b::82:0': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] error connecting to 'https://[2001:41d0:2:18b::82:0]:443': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] marking host '[2001:41d0:2:18b::82:0]' as dead
2018-10-01 14:25:17 dirmngr[23022.5] can't connect to '2a01:4f8:190:1150::111': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] error connecting to 'https://[2a01:4f8:190:1150::111]:443': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] marking host '[2a01:4f8:190:1150::111]' as dead
2018-10-01 14:25:17 dirmngr[23022.5] can't connect to '2001:67c:26b4::98:0': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] error connecting to 'https://[2001:67c:26b4::98:0]:443': Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] marking host '[2001:67c:26b4::98:0]' as dead
2018-10-01 14:25:17 dirmngr[23022.5] command 'KS_GET' failed: Network is unreachable
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> ERR 167805002 Network is unreachable <Dirmngr>
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 <- BYE
2018-10-01 14:25:17 dirmngr[23022.5] DBG: chan_5 -> OK closing connection
2018-10-01 14:25:17 dirmngr[23022.5] handler for fd 5 terminated

According gpg output:

gpg: keybox '/tmp/ks-test/run-hkps://hkps.pool.sks-keyservers.net-4/pubring.kbx' created
gpg: no running Dirmngr - starting '/opt/gnupg/bin/dirmngr'
gpg: waiting for the dirmngr to come up ... (5s)
gpg: connection to dirmngr established
gpg: keyserver receive failed: Network is unreachable

Details

Version
STABLE-BRANCH-2-2

Event Timeline

werner edited projects, added Feature Request, Keyserver; removed Bug Report.

It actually tries several servers but we need to set a limit because we need to cope with longer timeouts. Do you suggest to toggle between v4 and v6 addresses? That is if a v6 address fails, first try the next v4 address and it that fails, another v6 address, etc.

There is a solution for it:

RFC 8305 - Happy Eyeballs Version 2: Better Connectivity Using Concurrency
https://tools.ietf.org/html/rfc8305

I doubt that we are going to implement this.

Unusable v6 interfaces are now detected on Windows and then not used.