[tor-bugs] #9229 [Tor]: While bootstrapping, Tor clients stall for 60s when obfsproxy bridges are used.

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Mar 7 20:27:26 UTC 2014


#9229: While bootstrapping, Tor clients stall for 60s when obfsproxy bridges are
used.
-------------------------+-------------------------------------------------
     Reporter:  phw      |      Owner:  asn
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  60s, consensus, stall, obfsproxy,
Actual Points:           |  flashproxy, tbb-needs
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by nickm):

 Replying to [comment:17 nickm]:
 > So, reducing networkstatus_dl_check_interval() in the mainline code
 still makes me nervous.  I see two possible ways forward here:
  ...
 >  2. We could figure out what event (in this case) we should be
 triggering a download check in response to, and trigger a download check
 in response to that.

 This is the safer approach.

 I tried provoking the bug again, but adding a log message every time we
 are about to call UPDATE_NETWORKSTATUS_DOWNLOADS from main.c.  I saw:
 {{{
 Mar 07 15:21:49.000 [notice] Bootstrapped 5%: Connecting to directory
 server.
 Mar 07 15:21:49.000 [notice] UPDATE_NETWORKSTATUS_DOWNLOADS
 Mar 07 15:21:49.000 [notice] Bootstrapped 10%: Finishing handshake with
 directory server.
 Mar 07 15:21:49.000 [notice] Bootstrapped 15%: Establishing an encrypted
 directory connection.
 Mar 07 15:21:49.000 [notice] Bootstrapped 20%: Asking for networkstatus
 consensus.
 Mar 07 15:21:50.000 [notice] new bridge descriptor 'Unnamed' (fresh):
 $38FC956E026A600F4F66EA559D9CAAC4365E2C93~Unnamed at 192.36.31.159
 Mar 07 15:21:50.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Mar 07 15:21:50.000 [notice] new bridge descriptor 'braeu5' (fresh):
 $7683C2EA0896D5C3859CD594D691EE09831C1E8A~braeu5 at 90.225.64.7
 Mar 07 15:21:50.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Mar 07 15:21:50.000 [notice] new bridge descriptor 'Unnamed' (fresh):
 $476136C72FF5C937E97E95A7CFA5A44424237B5F~Unnamed at 188.165.251.124
 Mar 07 15:21:50.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.

  (long delay here)

 Mar 07 15:22:50.000 [notice] UPDATE_NETWORKSTATUS_DOWNLOADS
 Mar 07 15:22:50.000 [notice] Bootstrapped 25%: Loading networkstatus
 consensus.
 Mar 07 15:22:53.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Mar 07 15:22:53.000 [notice] Bootstrapped 40%: Loading authority key
 certs.
 }}}

 So there's a clue that we should be calling
 update_networkstatus_downloads() in response to getting new bridge
 descriptors if we don't have a fresh networkstatus.

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


More information about the tor-bugs mailing list