[tor-bugs] #11301 [Tor]: Tor does not reconnect after network loss with bridges

[Tor Bug Tracker & Wiki]

#11301: Tor does not reconnect after network loss with bridges
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  nickm
  mikeperry              |     Status:  needs_information
         Type:  defect   |  Milestone:  Tor: 0.2.5.x-final
     Priority:  major    |    Version:
    Component:  Tor      |   Keywords:  tor-client, tbb-usability, tbb-
   Resolution:           |  needs, 024-backport, 025-triaged, flashproxy,
Actual Points:           |  025-deferrable
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by dcf):

 attachment:oops.go is a pluggable transport that reproduces the refusal to
 reconnect. It drops its first `-n` connections after `-t` seconds. After
 that it works as a pass-through dummy transport. attachment:oops-torrc is
 a configuration for it.

 To build and run:
 {{{
 apt-get install golang (or http://golang.org/doc/install)
 export GOPATH=$PWD/go
 go get
 go build
 tor -f oops-torrc
 }}}

 The command line in oops-torrc is `./oops -t 3s -n 10 --log oops.log`.
 When I run tor, I get this in oops.log:
 {{{
 2014/04/23 20:38:37 starting [./oops -t 3s -n 10 --log oops.log]
 2014/04/23 20:38:39 got connection 0
 2014/04/23 20:38:42 oops! connection 0
 2014/04/23 20:38:49 got connection 1
 2014/04/23 20:38:52 oops! connection 1
 }}}
 and this in the tor output:
 {{{
 Apr 23 20:38:52.000 [info] circuit_build_failed(): Our circuit died before
 the first hop with no connection
 Apr 23 20:38:52.000 [info] entry_guard_register_connect_status(): Unable
 to connect to entry guard '3VXRyxz67OeRoqHn'
 (86FA348B038B6A04F2F50135BF84BB74EF63485B
 ). Marking as unreachable.
 Apr 23 20:38:53.000 [notice] Our directory information is no longer up-to-
 date enough to build circuits: We have no usable consensus.
 Apr 23 20:39:00.000 [info] compute_weighted_bandwidths(): Empty routerlist
 passed in to consensus weight node selection for rule weight as guard
 Apr 23 20:39:00.000 [info] smartlist_choose_node_by_bandwidth(): Empty
 routerlist passed in to old node selection for rule weight as guard
 Apr 23 20:39:00.000 [info] should_delay_dir_fetches(): Delaying dir
 fetches (no running bridges known)
 Apr 23 20:39:00.000 [info] compute_weighted_bandwidths(): Empty routerlist
 passed in to consensus weight node selection for rule weight as guard
 Apr 23 20:39:00.000 [info] smartlist_choose_node_by_bandwidth(): Empty
 routerlist passed in to old node selection for rule weight as guard
 Apr 23 20:39:00.000 [info] should_delay_dir_fetches(): Delaying dir
 fetches (no running bridges known)
 ...on and on...
 }}}
 You might have to play with the timeout and number of connections dropped.
 Try deleting datadir if it doesn't work the first time.

 tor seems to hang indefinitely if a disconnection happens during the
 fetching of descriptors (above 50% bootstrapped). A HUP will get it to
 make some more progress. I can also stimulate it into trying again by
 making a new SOCKS connection (`curl --socks5-hostname localhost:9099
 http://www.example.com`). I haven't figured out how to reproduce the issue
 where tor doesn't reconnect even though it gets new SOCKS connections,
 though I too have seen that before. It might have to do with the "Tried
 for 120 seconds to get a connection" error from #10993.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11301#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online