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:25 nickm]:
 > I'm not sure why the right fix here should involve changes to the
 directory fetch logic at all.  Wouldn't it be better to make it so that
 instead of having PTs go into a "maybe reset this; I'll figure it out
 later" state, we identify the ones that don't need to be reset
 immediately, and leave them alone?  Would that be super-hard?
 >

 I think this should be doable. It would probably require some non-trivial
 refactoring of the SIGHUP logic of `src/or/transports.c` (that part of the
 code is quite messy).

 I can look into this, but it might take me a few days.

 > I'm also not clear why we're using got_hup to indicate something that
 isn't "received a HUP" but is instead "the configuration changed at some
 point"

 That's a bad variable name. When I wrote that code, I didn't know much
 about Tor, and I thought that the only reason the config would be re-read
 was a `SIGHUP`.

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