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 asn):

 Replying to [comment:2 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.
 >

 Correct. That block was added in #11156, because Tor was trying to connect
 to destinations while the PTs were still doing the managed-proxy
 configuration protocol

 > 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?

 Hm, the managed-proxy configuration protocol takes 2-3 ticks of
 `run_scheduled_events()` to complete. Since in this case, bridge
 descriptors were read from disk (maybe using `router_reload_router_list`
 from `do_main_loop()`), it's likely that they were read and parsed before
 the PTs stopped configuring.

 Not sure what's the best fix here.

 A pretty stpid one that might work would be to move
 `router_reload_router_list()` only after PTs have been configured.

 Another fix might involve queuing up those descriptor/consensus fetches,
 and firing them up when PTs have been configured. This sounds a bit more
 involved, and requires good understanding of the networking logic of Tor
 (when documents get fetched, etc.) so that we don't mess things up.

 Another fix might involve performing the PT configuration protocol in a
 synchronous/blocking way immediately upon config read, so that we finish
 with it the soonest possible and stop worrying about it later. This might
 also be hard to evalute its correctness. I'm not sure how much time the PT
 configuration protocol would take if it was done synchronously; probably
 not too much. I'm only suggesting this because the same functionality
 caused another 60s bug in the past (ticket:11156:comment:19).

 More fix approaches are probably possible.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11965#comment:3>
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