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.
This commit is contained in:
Roger Dingledine 2021-10-22 02:33:49 -04:00
parent 867c3c6f89
commit 3c8510e2c0
2 changed files with 17 additions and 0 deletions

10
changes/bug40396 Normal file
View File

@ -0,0 +1,10 @@
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.

View File

@ -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();
}
/**