commit 3c8510e2c0b10637f4d2fdd81a6d0083968b7cc9 Author: Roger Dingledine <arma@torproject.org> Date: Fri Oct 22 02:33:49 2021 -0400 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. --- changes/bug40396 | 10 ++++++++++ src/feature/client/entrynodes.c | 7 +++++++ 2 files changed, 17 insertions(+) diff --git a/changes/bug40396 b/changes/bug40396 new file mode 100644 index 0000000000..f9d5b8ecb2 --- /dev/null +++ b/changes/bug40396 @@ -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. + diff --git a/src/feature/client/entrynodes.c b/src/feature/client/entrynodes.c index 315bd54674..efc1c07763 100644 --- a/src/feature/client/entrynodes.c +++ b/src/feature/client/entrynodes.c @@ -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(); } /**