commit 5298ab59170be74aed20e04e5378ec66eef6476e Author: Nick Mathewson <nickm@torproject.org> 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);