commit 3c8510e2c0b10637f4d2fdd81a6d0083968b7cc9
parent 867c3c6f89ae67bb95cc3c714feb7898dd3c8e3b
Author: Roger Dingledine <arma@torproject.org>
Date: Fri, 22 Oct 2021 02:33:49 -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.
Diffstat:
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/changes/bug40396 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
@@ -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();
}
/**
