[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs