#24367: Changing pluggable transports (during start-up) in Tor Browser is broken -------------------------------------------------+------------------------- Reporter: gk | Owner: (none) Type: defect | Status: | needs_information Priority: Medium | Milestone: Tor: | 0.3.2.x-final Component: Core Tor/Tor | Version: Tor: | 0.3.2.1-alpha Severity: Normal | Resolution: Keywords: regression, tor-bridge-client, | Actual Points: s8-errors, tbb-wants | Parent ID: | Points: 0.5 Reviewer: | Sponsor: | Sponsor8-can -------------------------------------------------+-------------------------
Comment (by teor): I think we might have fixed some more parts of this issue in #24392: we now distinguish between bridges that might be reachable, and bridges that are definitely reachable. This partially reverts some of the changes in #23347 and #17750: * we only delay bridge descriptor fetches when we have a bridge that is definitely running, * we only delay directory fetches when all of our bridges are definitely not running, * we keep on retrying directory downloads every time we receive a new bridge descriptor, until we definitely have a reachable bridge. Please re-test my branch bug24367_032 from github. Replying to [comment:17 gk]: > If you look at the log for d7833c9d27feed9 you'll see that the guard list gets updated with `obfs4` bridges as is done in the log for 6370fb77c586e9a: > {{{ > Nov 22 11:37:05.000 [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is: > Nov 22 11:37:05.000 [info] entry_guards_update_primary(): 1/3: [bridge] ($A832D176ECD5C7C6B58825AE22FC4C90FA249637) > Nov 22 11:37:05.000 [info] entry_guards_update_primary(): 2/3: [bridge] ($D9A82D2F9C2F65A18407B1D2B764F130847F8B5D) > Nov 22 11:37:05.000 [info] entry_guards_update_primary(): 3/3: [bridge] ($CDF2E852BF539B82BD10E27E9115A31734E378C2) > }}} > So, that part is good. However and contrary to what is happening in the 6370fb77c586e9a case those are not getting used/tried. Rather, the previously used `obfs3` bridge is still present: > {{{ > Nov 22 11:37:06.000 [info] sample_reachable_filtered_entry_guards(): (Selected [bridge] ($A09D536DD1752D542E1FBB3C9CE4449D51298239).) > Nov 22 11:37:06.000 [info] select_entry_guard_for_circuit(): No primary or confirmed guards available. Selected random guard [bridge] ($A09D536DD1752D542E1FBB3C9CE4449D51298239) for circuit. Will try other guards before using this circuit. > }}} This looks like a bug in sample_reachable_filtered_entry_guards(). It looks like we are keeping the old bridge (A09D536DD1752D542E1FBB3C9CE4449D51298239) as a possible non-primary non- confirmed guard, even when it is no longer configured as a bridge. That's not good at all. We should be discarding it entirely. I'm going to leave this to someone else to fix. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24367#comment:23> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs