Opened 5 years ago

Closed 5 years ago

#10993 closed defect (duplicate)

Fails to reconnect after connection loss when only one bridge is configured

Reported by: lunar Owned by:
Priority: Medium Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client, bridges, 025-triaged, flashproxy, 025-deferrable
Cc: asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When configured to use only a single bridge, if the connection to that bridge is lost (which typically happen when suspending or hoping from one network to another), tor will not try to reconnect even when the bridge is reachable available again.

At notice level, you can see a loop of:

smartlist_choose_node_by_bandwidth(): Empty routerlist passed in to old node selection for rule weight as guard
should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as guard

I don't think this happen when there is more than one bridge configure but I'm not 100% sure at this time.

I also have the feeling that this did not happen with version 0.2.3, but I'm not 100% sure either.

Child Tickets

Change History (8)

comment:1 Changed 5 years ago by nickm

Keywords: tor-client bridges added
Milestone: Tor: 0.2.5.x-final

Can you test with 0.2.3 and/or 0.2.4? It would be great to know if there is new/changed behavior here.

If this is a regression, it's much easier to figure it out and fix it than if it is new behavior.

comment:2 Changed 5 years ago by kargig

I can confirm the problem with a single bridge that it "never" reconnects (I've waited max for 12 minutes).

But reconnection takes a very long time even when one has two bridges configured. I have two in my config and when I switch my default route (eg exit my VPN) then Tor refuses to recreate any circuits for a very long time.

Here's the (relevant) Tor log

Mar 06 19:12:54.000 [notice] Bridge 'aaaa' has both an IPv4 and an IPv6 address.  Will prefer using its IPv4 address (X.Y.Z.W:12345).
Mar 06 19:12:54.000 [notice] new bridge descriptor 'aaaa' (fresh): $xxxxxxxx at X.Y.Z.W
Mar 06 20:12:54.000 [notice] Bridge 'bbbb' has both an IPv4 and an IPv6 address.  Will prefer using its IPv4 address (A.B.C.D:23456).
Mar 06 20:12:54.000 [notice] new bridge descriptor 'bbbb' (fresh): $yyyyyyyy at A.B.C.D
Mar 06 20:26:57.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $6218B1A77845ED3CC8F730D770E6DE21790F0E48~ArachnideFR35v2 at 95.130.9.190. Retrying on a new circuit.
Mar 06 20:28:43.000 [warn] Application request to port 143: this port is commonly used for unencrypted protocols. Please make sure you don't send anything you would mind the rest of the Internet reading!
Mar 06 20:29:43.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:5222. Giving up. (waiting for circuit)
Mar 06 20:29:48.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:5222. Giving up. (waiting for circuit)
Mar 06 20:30:48.000 [warn] Application request to port 143: this port is commonly used for unencrypted protocols. Please make sure you don't send anything you would mind the rest of the Internet reading!
Mar 06 20:32:17.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:5222. Giving up. (waiting for circuit)
Mar 06 20:32:37.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:5222. Giving up. (waiting for circuit)
Mar 06 20:34:10.000 [notice] Tor has not observed any network activity for the past 567 seconds. Disabling circuit build timeout recording.
Mar 06 20:34:10.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We have no usable consensus.
Mar 06 20:34:26.000 [notice] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
Mar 06 20:34:26.000 [notice] We now have enough directory information to build circuits.
Mar 06 20:34:26.000 [notice] Tor now sees network activity. Restoring circuit build timeout recording. Network was down for 583 seconds during 2 circuit attempts.
Mar 06 20:34:27.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.

I exit my VPN:

Thu Mar  6 20:24:48 2014 SIGINT[hard,] received, process exiting

And start trying to connect through Tor

$ date && usewithtor curl -v torproject.org
Thu Mar  6 20:26:15 EET 2014
* Rebuilt URL to: torproject.org/
* Hostname was NOT found in DNS cache

$ date && usewithtor curl -v torproject.org
Thu Mar  6 20:28:43 EET 2014
* Rebuilt URL to: torproject.org/
* Hostname was NOT found in DNS cache

$ date && usewithtor curl -v torproject.org
Thu Mar  6 20:34:38 EET 2014
* Rebuilt URL to: torproject.org/
* Hostname was NOT found in DNS cache
*   Trying 38.229.72.14...
* Connected to torproject.org () port 80 (#0)

Isn't 567 seconds a bit too much to wait for a reconnect? I'm using Tor 0.2.4.21 (git-c5a648cc6f218339)

comment:3 Changed 5 years ago by mikeperry

Something similar is happening to Yawning and I with multiple bridges/PTs in 0.2.4.x. See #11301.

Version 0, edited 5 years ago by mikeperry (next)

comment:4 Changed 5 years ago by nickm

Keywords: 025-triaged added

Is this the same as #11301 , or are they different somehow?

comment:5 Changed 5 years ago by dcf

Keywords: flashproxy added

comment:6 Changed 5 years ago by nickm

Keywords: 025-deferrable added
Status: newneeds_information

We really need easy instructions on how to reproduce these, or we probably won't be able to get a fix done for 0.2.5.

comment:7 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

This is looking like it's going to get deferred to 0.2.6 unless either:

  • it turns out to be the same as #11301 , and we fix #11301
  • somebody shows up with instructions for reproducing this.

So, moving this to 0.2.6. It can get moved back if one of those situations comes up.

comment:8 Changed 5 years ago by lunar

Resolution: duplicate
Status: needs_informationclosed

Let's assume this is the same as #11301.

Note: See TracTickets for help on using tickets.