Re: [tor-bugs] #11965 [Tor]: 60-second pause bootstrapping with a bridge if you already have its descriptor

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#11965: 60-second pause bootstrapping with a bridge if you already have its
descriptor
------------------------+--------------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  needs_review
     Priority:  normal  |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-bridge
Actual Points:          |  Parent ID:
       Points:          |
------------------------+--------------------------------

Comment (by arma):

 So, my 'third step' is suspicious -- on the second run, shouldn't that
 routerlist_retry_directory_downloads() be triggering some consensus
 fetches as soon as the bridge descriptor is read from disk?

 And the answer is:
 {{{
 May 14 23:32:11.000 [notice] new bridge descriptor 'Unnamed' (cached):
 $AF9F66B7B04F8FF6F32D455F05135250A16543C9~Unnamed at 169.229.59.74
 May 14 23:32:11.000 [info] should_delay_dir_fetches(): Delaying dir
 fetches (pt proxies still configuring)
 }}}

 So it does trigger the fetches, but they get cancelled because the pt
 proxies are still in progress at that point.

 Which leads me to ask: is there anything that gets triggered when
 pt_proxies_configuration_pending() transitions from true to false, or is
 it likely we have a race condition here if it takes a while to configure
 our PTs?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11965#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs