[tor-bugs] #21052 [Core Tor/Tor]: Bad prop271 behavior when exhausting all guards
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Dec 21 12:41:09 UTC 2016
#21052: Bad prop271 behavior when exhausting all guards
------------------------------+--------------------------------
Reporter: asn | Owner:
Type: defect | Status: new
Priority: Medium | Milestone: Tor: 0.3.1.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: prop271, tor-guard
Actual Points: | Parent ID: #20822
Points: 0.7 | Reviewer:
Sponsor: |
------------------------------+--------------------------------
Here is a weird prop271 behavior. If you get Tor to exhaust all of its
primary/confirmed/sampled guards, it will just get stuck until a guard
gets
marked for retry (which can take half an hour or more).
Specifically, if you disable the network until Tor starts hitting:
{{{
if (guard == NULL) {
log_warn(LD_GUARD, "Absolutely no sampled guards were available.");
return NULL;
}
}}}
it will just get stuck in a `"Absolutely no sampled guards were
available."`
loop until a guard gets marked for retry.
In our pre-prop271 guard algorithm, we used to mark all guards as
retriable if
we exhaust all of them. I think this is a strictly better behavior than
just
waiting until a guard retry timeout triggers.
Furthermore in our pre-prop271 guard algorithm, when we exhaust all of our
guards, we mark our network as likely-down. The idea is that if our
network was
marked as likely-down and then we managed to connect to a guard, we would
treat
that as a network-up event and then start trying guards from the top of
our
list.
This was a pretty effective heuristic that really saved lots of guard
exposure
to people with unstable internet. We have a similar one for prop271 but
it's
only based on time (get_internet_likely_down_interval() etc.) and not on
behavior. I think doing
this old heuristic in prop271 might be a great idea. Here is how it could
work:
When we exhaust all our guards, we mark all guards as retriable. The next
time
we manage to connect to a guard, we stall the circuit and we call
mark_primary_guards_maybe_reachable() so that we attempt to connect to our
primaries again, before using that low-priority guard.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21052>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list