[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3589 [Tor Bridge]: Advertise bridge pluggable transports using extra-info lines
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs