[tor-bugs] #9557 [Tor]: Clients waste a whole minute when bootstrapping using bridges

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Aug 21 19:15:19 UTC 2013


#9557: Clients waste a whole minute when bootstrapping using bridges
------------------------+---------------------------------------------------
 Reporter:  karsten     |          Owner:     
     Type:  defect      |         Status:  new
 Priority:  normal      |      Milestone:     
Component:  Tor         |        Version:     
 Keywords:  tor-client  |         Parent:     
   Points:              |   Actualpoints:     
------------------------+---------------------------------------------------
 When a client bootstraps for the first time using bridges, it sits there
 for a whole minute doing nothing between "Bootstrapped 50%" and
 "Bootstrapped 80%":

 {{{
 Aug 21 19:08:20.804 [notice] Tor 0.2.5.0-alpha-dev (git-7121e7bd15659052)
 opening log file.
 Aug 21 19:08:20.805 [warn] Your log may contain sensitive information -
 you're logging above "notice". Please log safely. Don't log unless it
 serves an important reason. Overwrite the log afterwards.
 Aug 21 19:08:20.805 [warn] Your log may contain sensitive information -
 you disabled SafeLogging. Please log safely. Don't log unless it serves an
 important reason. Overwrite the log afterwards.
 Aug 21 19:08:21.923 [notice] Bootstrapped 5%: Connecting to directory
 server.
 Aug 21 19:08:21.925 [notice] Bootstrapped 10%: Finishing handshake with
 directory server.
 Aug 21 19:08:21.942 [notice] Learned fingerprint
 224FC9615C2899B3C982A947FF7912201F986B1C for bridge 174.129.86.221:9001.
 Aug 21 19:08:21.942 [notice] Bootstrapped 15%: Establishing an encrypted
 directory connection.
 Aug 21 19:08:21.985 [notice] Bootstrapped 20%: Asking for networkstatus
 consensus.
 Aug 21 19:08:21.987 [notice] Bootstrapped 50%: Loading relay descriptors.
 Aug 21 19:08:21.993 [notice] new bridge descriptor 'utpbridge' (fresh):
 $224FC9615C2899B3C982A947FF7912201F986B1C~utpbridge at 174.129.86.221
 Aug 21 19:08:21.993 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Aug 21 19:09:23.194 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Aug 21 19:09:23.390 [notice] I learned some more directory information,
 but not enough to build a circuit: We need more microdescriptors: we have
 0/4455, and can only build 0% of likely paths. (We have 0% of guards bw,
 0% of midpoint bw, and 0% of exit bw.)
 Aug 21 19:09:24.928 [notice] We now have enough directory information to
 build circuits.
 Aug 21 19:09:24.928 [notice] Bootstrapped 80%: Connecting to the Tor
 network.
 Aug 21 19:09:24.930 [notice] Bootstrapped 90%: Establishing a Tor circuit.
 Aug 21 19:09:26.162 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Aug 21 19:09:26.162 [notice] Bootstrapped 100%: Done.
 }}}

 My current theory is that the first directory request fetches the bridge's
 server descriptor, which works fine.  But then the client sees that it
 doesn't have a microdesc consensus, decides that it just finished a
 directory request, so schedules the next request for in a minute later.
 What it should really do is make another request right then.

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


More information about the tor-bugs mailing list