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.

diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c
index 729e4b0391e80523545c8afdc8c123a05a516750..c3c576c8124ac0b6c1ec6f9e4556ae1f7f1a690e 100644 (file)
--- 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);