[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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

Comment (by asn):

 After a little bit of debugging, I found out that the errors were thrown
 because we tried to create an OR connection before the managed proxy was
 finished configuring (managed proxies are configured with a configuration
 protocol, that takes a bit of time).

 ATM, we are blocking bridge descriptor fetches when PTs haven't finished
 configuring, by doing:
 {{{
   if (pt_proxies_configuration_pending())
     return;
 }}}
 in `fetch_bridge_descriptors()`. But apparently, blocking that function is
 not sufficient to postpone all OR connections.

 For example, the errors in brade's bug were caused because of the:
 {{{
 ...
 #12 0x0000555555633c43 in directory_initiate_command (if_modified_since=0,
 payload_len=0, payload=0x0, resource=0x55555568a2c7 "microdesc",
 indirection=DIRIND_ONEHOP, router_purpose=0 '\000', dir_purpose=14 '\016',
     digest=0x555555c5f27c
 "\240\235Sm\321u-T.\037\273<\234\344D\235Q)\202\071\020\313\031S",
 dir_port=0, or_port=<optimized out>, _addr=0x7fffffffdfa0,
 address=<optimized out>) at src/or/directory.c:878
 #13 directory_get_from_dirserver (dir_purpose=dir_purpose@entry=14 '\016',
 router_purpose=router_purpose@entry=0 '\000', resource=<optimized out>,
 resource@entry=0x55555568a2c7 "microdesc", pds_flags=pds_flags@entry=2)
     at src/or/directory.c:467
 #14 0x000055555558c354 in update_consensus_networkstatus_downloads
 (now=now@entry=1394201439) at src/or/networkstatus.c:767
 #15 0x000055555558dd40 in update_networkstatus_downloads (now=1394201439)
 at src/or/networkstatus.c:906
 #16 0x0000555555586c0d in run_scheduled_events (now=1394201439) at
 src/or/main.c:1468
 ....
 }}}
 codepath. This means that maybe we should also block entry to
 `update_consensus_networkstatus_downloads()` if
 `pt_proxies_configuration_pending()`. I made a small patch that did that,
 and it seems to solve the error messages in this case.

 But how can we be sure that we have blocked all the relevant codepaths
 that might launch an OR connection before PTs have been configured?

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