Fails to reconnect after connection loss when only one bridge is configured
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 guardI 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.
Activity
changed milestone to %Tor: 0.2.6.x-final
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 exitingAnd 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)
Trac:
Username: kargig
Something similar is happening to Yawning and me with multiple bridges/PTs in 0.2.4.x. The HUP signal fixes it. See #11301 (moved).
Is this the same as #11301 (moved) , or are they different somehow?
Trac:
Keywords: tor-client bridges deleted, tor-client bridges 025-triaged added-
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 (moved) , and we fix #11301 (moved)
- 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.
Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.6.x-final 
Let's assume this is the same as #11301 (moved).
Trac:
Status: needs_information to closed
Resolution: N/A to duplicatementioned in issue #11301 (moved)
mentioned in issue #11562 (moved)
moved to tpo/core/tor#10993 (closed)