Re: [tor-bugs] #11156 [Tor]: "can't find a pluggable transport proxy" errors when obfsproxy started up

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

#11156: "can't find a pluggable transport proxy" errors when obfsproxy started up
-------------------------+-------------------------------------------------
     Reporter:  asn      |      Owner:
         Type:  defect   |     Status:  needs_revision
     Priority:  normal   |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  024-backport tor-pt tor-client,
Actual Points:           |  tbb-needs
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by asn):

 Replying to [comment:21 nickm]:
 > Okay, this is sounding non-backportable, but the new stuff needs review.
 (Is the RESETCONF issue so bad that we should just revert the fix and push
 this into 0.2.6? Did RESETCONF work before we merged this?)
 >

 I'm not sure if we should revert this fix, but it indeed does expose
 another 60s bug.

 FWIW, `RESETCONF` works currently without any issues. It's just that when
 you call `RESETCONF` (or any other command that re-reads the torrc)
 between the point where you get the bridge descriptor and the point where
 you need to fetch the other directory documents, Tor gets confused and
 causes a 60s bug.

 This 60s bug is not #9229, or at least the fix of #9229 doesn't fix it.
 The fix of #9229 asks for a fetch of all directory documents when we
 receive the first bridge descriptor. In this case, that fetch will get
 delayed because we have just re-read our torrc (because `RESETCONF`), and
 our PT proxies are marked for possible restart (part of the SIGHUP
 mechanism), and hence `should_delay_dir_fetches()` returns true.

 Did this make it more clear?

 > I really don't like "solve the problem by lowering an interval" fixes;
 those intervals are there to avoid runaway loops.  If there's something
 that needs to get done faster than the "check" interval, the right
 solution is to have the thing that should trigger a re-check reset the
 timer for the interval.

 I see what you are saying.

 Then a fix here might be to call `routerlist_retry_directory_downloads()`
 when our PTs move from the ''might need to be restarted'' state to the
 ''restarted''/''not restarted'' state: this happens in every `SIGHUP` or
 config reread (`SETCONF`/`RESETCONF`/etc.).

 However, if we do this we will end up calling that function needlessly
 sometimes (actually almost all times; since this bug needs good timing to
 trigger).

 Maybe a better fix would be to call
 `routerlist_retry_directory_downloads()` when our PTs move to the
 ''restarted''/''not restarted'' phase '''but only if''' they had delayed a
 descriptor fetch? This will be a bit messier to code, but I think it's
 doable.

 (PS: Pluggable Transport proxies are marked for ''might need to be
 restarted'' in every config read, so that we can figure out whether their
 `ClientTransportPlugin`/`ServerTransportPlugin` line changed. If their
 torrc line changed, Tor will try to restart them in place, to cause a
 seamless SIGHUP experience. In the end of `run_sheduled_events()` we run
 `pt_configure_remaining_proxies()` which moves the PT proxies from the
 ''might need to be restarted'' to the ''restrarted''/''not restarted''
 state.)

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