GitLab

If you look at the bottom of https://consensus-health.torproject.org/#relayinfo and put in 'dannenberg' and click load, right now you will find that moria1, dannenberg, faravahar, and bastet think that dannenberg is Running, but the rest of the dir auths think it isn't Running.

My laptop, running Debian stable and Tor git master, is unable to connect to it:

$ src/app/tor usebridges 1 bridge 193.23.244.244:443
Mar 24 17:48:32.903 [notice] Tor 0.4.6.1-alpha-dev (git-f6af8e2021179498) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd N/A and Glibc 2.28 as libc.
[...]
Mar 24 17:48:36.253 [notice] Delaying directory fetches: No running bridges
Mar 24 17:48:37.257 [notice] Bootstrapped 5% (conn): Connecting to a relay
Mar 24 17:48:37.355 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Mar 24 17:48:37.560 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Mar 24 17:53:01.016 [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (IOERROR; IOERROR; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 193.23.244.244:443)
Mar 24 17:53:01.016 [warn] 1 connections have failed:
Mar 24 17:53:01.016 [warn]  1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Mar 24 17:57:01.959 [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (IOERROR; IOERROR; count 2; recommendation warn; host 0000000000000000000000000000000000000000 at 193.23.244.244:443)
Mar 24 17:57:01.959 [warn] 2 connections have failed:
Mar 24 17:57:01.959 [warn]  2 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN

And indeed, the ssl-related logs right before the 14% bootstrap mark say

Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS read finished [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS write change cipher spec [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS write client certificate [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS write finished [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSL negotiation finished successfully [type=32,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSL negotiation finished successfully [type=4098,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_handshake(): After call, 0x562d6188b920 was in state SSL negotiation finished successfully

@dgoulet says he can bootstrap with dannenberg, and indeed around half of the dir auths can so it's not super surprising that he can.

It's not an internet routing thing, because my laptop can reach the port just fine and do the TCP handshake just fine.

I had assumed it is related to #40128 but the dannenberg operator believes they are running the fixed version of libressl.

We've had more user support requests than usual for "my relay / bridge says it's not reachable" so I think there is some bug remaining here.

dannenberg is on OpenBSD 6.8 with LibreSSL 3.2.2. One hint is that the Andreas gave us is that he found this in the changelog:

013: RELIABILITY FIX: February 3, 2021 All architectures Various interoperability issues and memory leaks were discovered in libcrypto and libssl.

https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/013_libressl.patch.sig