Obfs4: dysfunctional Error: timed out waiting for bridge descriptor

7e8e · May 3, 2022, 6:02am

I’ve run a relay out of my house and one in a data center. I ran a bridge in a data center. All OK.

But trying to bring the bridge into the house on a NUC is giving me the following error.

There is nothing in the log that is complaining.

The ports are reachable from the Internet.

When I start the relay, I see a few connections and then within 30 minutes, they drop. I’m used to seeing an update on how many clients were seen but I’m not seeing that.

I’m thinking of scratching the OS and start again. This error is very rare in Google.

Any pointers appreciated.

Bridge * advertises:

* obfs4: dysfunctional
  Error: timed out waiting for bridge descriptor
  Last tested: 2022-05-03 00:38:31.494408719 +0000 UTC (3h8m7.161881599s ago)

May 02 22:40:14.314 [notice] We compiled with OpenSSL 101010df: OpenSSL 1.1.1m  14 Dec 2021 and we are running with OpenSSL 101010df: 1.1.1m. These two versions should be binary compatible.
May 02 22:40:14.373 [notice] Tor 0.4.6.9 (git-ea2ada6d1459f829) running on Windows 8 [or later] with Libevent 2.1.12-stable, OpenSSL 1.1.1m, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Unknown N/A as libc.
May 02 22:40:14.375 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 02 22:40:14.475 [notice] Read configuration file "*\tor\torrc".
May 02 22:40:14.481 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand.
May 02 22:40:14.488 [notice] Opening OR listener on *:9001
May 02 22:40:14.488 [notice] Opened OR listener connection (ready) on *:9001
May 02 22:40:14.488 [notice] Opening Extended OR listener on 127.0.0.1:0
May 02 22:40:14.488 [notice] Extended OR listener listening on port 50638.
May 02 22:40:14.488 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:50638
May 02 22:41:34.000 [notice] Parsing GEOIP IPv4 file *\geoip.
May 02 22:41:35.000 [notice] Parsing GEOIP IPv6 file *\geoip6.
May 02 22:41:36.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
May 02 22:41:37.000 [notice] Your Tor server's identity key  fingerprint is '* *'
May 02 22:41:37.000 [notice] Your Tor bridge's hashed identity key  fingerprint is '(* *'
May 02 22:41:37.000 [notice] Your Tor server's identity key ed25519 fingerprint is '* *'
May 02 22:41:37.000 [notice] You can check the status of your bridge relay at https://bridges.torproject.org/status?id=*
May 02 22:41:37.000 [notice] Bootstrapped 0% (starting): Starting
May 02 22:44:01.000 [notice] Starting with guard context "default"
May 02 22:44:01.000 [notice] Registered server transport 'obfs4' at '*:443'
May 02 22:44:02.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
May 02 22:44:02.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
May 02 22:44:02.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
May 02 22:44:03.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
May 02 22:44:03.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
May 02 22:44:03.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
May 02 22:44:03.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
May 02 22:44:04.000 [notice] Bootstrapped 100% (done): Done
May 02 22:44:04.000 [notice] Now checking whether IPv4 ORPort *:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
May 02 22:44:05.000 [notice] Self-testing indicates your ORPort *:9001 is reachable from the outside. Excellent. Publishing server descriptor.
May 02 22:44:10.000 [notice] Performing bandwidth self-test...done.

= Real values obscured

gus · May 3, 2022, 7:07pm

Hi @7e8e, have you tried to connect to your own bridge? You can find instructions here:

7e8e · May 3, 2022, 10:48pm

I find this confusing:

Paste the entire bridge line into Tor Browser:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Paste it where? URL bar? Put it into a file? Put it into the bridge line in the client?

Does fingerprint include the nickname like it does in the notices file?

An example would be helpful.

I really want this to work. The NUC is perfect for set and forget.

Serge is connecting and dropping out. I put on a new NIC.

If I can get the answer to the above, I’d appreciate it.

I’ll report back when the bridge status page updates with the new NIC.

gus · May 4, 2022, 12:59pm

Thanks for your feedback. I will add a link.

Meanwhile, you can follow the Tor Browser User manual:

If you’re starting Tor Browser for the first time, click “Tor Network Settings” to open the Tor settings window. Under the “Bridges” section, select the checkbox “Use a bridge”, choose “Provide a bridge I know” and enter each bridge address on a separate line. Click “Connect” to save your settings.

Or, if you have Tor Browser running, click on “Preferences” (or “Options” on Windows) in the hamburger menu (≡) and then on “Tor” in the sidebar. In the “Bridges” section, select the checkbox “Use a bridge”, and from the option “Provide a bridge I know”, enter each bridge address on a separate line. Your settings will automatically be saved once you close the tab.

7e8e · May 4, 2022, 8:40pm

Thank you. I will consult the guild.

I am aware of the location of “Provide ea bridge” and I know roughly how to construct the entry.

However, it states “address:port” which suggests something more simple.

I have had one connection from the outside, “* obfs4: functional” is showing as bridge status and there are no errors in noticest.txt.

It seems to be working now.

Thank you.

gus · May 4, 2022, 8:52pm

Yes, and that isn’t correct. We have this ticket to track this bug:

If you use a bridge IP:ORPort (and not OBFS4 port), you will connect without any pluggable transport, i.e., a “vanilla” Tor bridge. But if you paste or type only the bridge IP:OBFSPort without adding the full line (fingerprint, cert, iat-mode) you won’t be able to connect.

fortuna · January 10, 2023, 5:59pm

How did you solve the Error: timed out waiting for bridge descriptor?
I get the same error.

flameshretoos · March 25, 2024, 11:48am

Run hardware tests to check the integrity of your NUC’s network hardware. Issues with the Network Interface Card (NIC) can lead to dropped connections. ISP and Router. Verify with your ISP if there are any known issues, especially if IPv6 is being rolled out in your area, as this can cause compatibility issues with certain Ethernet controllers. Use network monitoring tools like iPerf to analyze your network’s performance and identify potential bottlenecks or stability issues. Before you decide to reinstall the OS, it might be worth trying these steps to see if they resolve the issue. If the problem persists, a fresh OS installation could indeed be a last resort. Remember to back up any important data before proceeding with the OS reinstallation.