[tor-commits] [tor/release-0.3.0] Restore correct behavior of 0.3.0.4-rc with bridges+ipv6-min

[nickm@xxxxxxxxxxxxxx]

commit 5298ab59170be74aed20e04e5378ec66eef6476e
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Wed Mar 1 15:02:16 2017 -0500

    Restore correct behavior of 0.3.0.4-rc with bridges+ipv6-min
    
    In that chutney test, the bridge client is configured to connect to
    the same bridge at 127.0.0.1:5003 _and_ at [::1]:5003, with no
    change in transports.
    
    That meant, I think, that the descriptor is only assigned to the
    first bridge when it arrives, and never the second.
---
 src/or/entrynodes.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c
index 729e4b0..c3c576c 100644
--- a/src/or/entrynodes.c
+++ b/src/or/entrynodes.c
@@ -3365,7 +3365,14 @@ guard_selection_have_enough_dir_info_to_build_circuits(guard_selection_t *gs)
    * guards in our list, since these are the guards that we typically use for
    * circuits. */
   num_primary_to_check = get_n_primary_guards_to_use(GUARD_USAGE_TRAFFIC);
-  num_primary_to_check++;
+  /*
+    We had added this to try to guarantee that we'd not normally try a guard
+    without a descriptor, even if we didn't use the first guard.  But it led
+    to problems with the chutney bridges+ipv6-min test.  A better solution is
+    needed.
+
+    num_primary_to_check++;
+  */
 
   SMARTLIST_FOREACH_BEGIN(gs->primary_entry_guards, entry_guard_t *, guard) {
     entry_guard_consider_retry(guard);



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits