[tor-bugs] #3589 [Tor Bridge]: Advertise bridge pluggable transports using extra-info lines

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Thu Jan 26 01:45:08 UTC 2012


#3589: Advertise bridge pluggable transports using extra-info lines
-------------------------+--------------------------------------------------
 Reporter:  asn          |          Owner:                    
     Type:  enhancement  |         Status:  new               
 Priority:  normal       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor Bridge   |        Version:                    
 Keywords:               |         Parent:  #4685             
   Points:               |   Actualpoints:                    
-------------------------+--------------------------------------------------

Comment(by asn):

 Nick, I'm looking at how and when descriptors are generated. Managed
 proxies are configured step-by-step in `run_scheduled_events()`, and
 sometimes they require one or two ticks to get finalized. Meanwhile,
 `router_rebuild_descriptor()` and its callers are called from many
 codepaths, and I'm worrying that we might generate a descriptor before all
 managed proxies are fully configured (which means that the descriptor
 won't list all the transports we support).

 In my tests, the bridge always builds a descriptor after managed proxies
 are configured [0], but I'm not confident that this will always be true.

 Do you think it's acceptable to check if `router.c:desc_routerinfo` is
 non-NULL, right after all managed proxies are configured (using
 `pt_proxies_configuration_pending()` in `run_scheduled_events()`)? If we
 already had generated a descriptor (that is, `desc_routerinfo` is non-
 NULL), we should generate a new one (now that all transports are
 registered) and re-publish it.

 [0]:
 {{{
 Breakpoint 1, extrainfo_dump_to_string (s_out=0x83df7a8,
 extrainfo=0x83df7a8, ident_key=0x81c0280) at router.c:2242
 2242    {
 (gdb) bt
 #0  extrainfo_dump_to_string (s_out=0x83df7a8, extrainfo=0x83df7a8,
 ident_key=0x81c0280) at router.c:2242
 #1  0x080812a2 in router_rebuild_descriptor (force=0) at router.c:1629
 #2  0x080817d3 in router_get_my_routerinfo () at router.c:1408
 #3  0x080eadd5 in directory_conn_is_self_reachability_test
 (conn=0xb68011a8) at directory.c:636
 #4  0x080f3578 in connection_dir_client_reached_eof (conn=<optimized out>)
 at directory.c:1979
 #5  0x080f506e in connection_dir_reached_eof (conn=0xb68011a8) at
 directory.c:2256
 #6  0x080d0423 in connection_reached_eof (conn=0xb68011a8) at
 connection.c:3872
 #7  connection_handle_read_impl (conn=0xb68011a8) at connection.c:2685
 #8  connection_handle_read (conn=0xb68011a8) at connection.c:2697
 #9  0x08051b14 in conn_read_callback (fd=-1, event=2, _conn=0xb68011a8) at
 main.c:702
 #10 0x0017c0c9 in event_base_loop () from /usr/lib/libevent-2.0.so.5
 #11 0x08052a24 in do_main_loop () at main.c:1924
 #12 0x080541e5 in tor_main (argc=3, argv=0xbffff454) at main.c:2619
 #13 0x0804f1cb in main (argc=3, argv=0xbffff454) at tor_main.c:30
 }}}

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3589#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list