[tor-commits] [tor/main] reassess minimum-dir-info when a bridge fails

[ahf at torproject.org]

commit 3c8510e2c0b10637f4d2fdd81a6d0083968b7cc9
Author: Roger Dingledine <arma at 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();
 }
 
 /**