Commit 3c8510e2 authored by Roger Dingledine's avatar Roger Dingledine
Browse files

reassess minimum-dir-info when a bridge fails

When we try to fetch a bridge descriptor and we fail, we mark
the guard as failed, but we never scheduled a re-compute for
router_have_minimum_dir_info().

So if we had already decided we needed to wait for this new descriptor,
we would just wait forever -- even if, counterintuitively, *losing* the
bridge is just what we need to *resume* using the network, if we had it
in state GUARD_REACHABLE_MAYBE and we were stalling to learn this outcome.

See bug 40396 for more details.
parent 867c3c6f
o Major bugfixes (bridges):
- Make Tor work reliably again when you have multiple bridges
configured and one or more of them are unreachable. The problem
came because we require that we have bridge descriptors for both
of our first two bridges (else we refuse to try to connect), but
in some cases we would wait three hours before trying to fetch
these missing descriptors, and/or never recover when we do try
to fetch them. Fixes bugs 40396 and 40495; bugfix on 0.3.0.5-rc
and 0.3.2.1-alpha.
......@@ -2271,6 +2271,13 @@ entry_guards_note_guard_failure(guard_selection_t *gs,
guard->is_primary?"primary ":"",
guard->confirmed_idx>=0?"confirmed ":"",
entry_guard_describe(guard));
/* Schedule a re-assessment of whether we have enough dir info to
* use the network. Counterintuitively, *losing* a bridge might actually
* be just what we need to *resume* using the network, if we had it in
* state GUARD_REACHABLE_MAYBE and we were stalling to learn this
* outcome. See bug 40396 for more details. */
router_dir_info_changed();
}
/**
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment