#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.0.1-alpha Severity: Normal | Resolution: Keywords: 030-backport, 031-backport, | Actual Points: regression, tor-bridge-client, s8-errors, | tbb-wants | Parent ID: | Points: 0.5 Reviewer: | Sponsor: | Sponsor8-can -------------------------------------------------+-------------------------
Comment (by gk): Replying to [comment:23 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. I did. Here is the good news: it seems this branch fixes the "even worse" part in my comment:description. > 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. I wonder if that's the reason for the issue outlined in steps 1)-4) in my comment:description as that one is not resolved yet with your `bug24367_032`. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24367#comment:25> 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