don't retry entry guards if they're bridges without descriptors

When we don't yet have a descriptor for one of our bridges, disable
the entry guard retry schedule on that bridge. The entry guard retry
schedule and the bridge descriptor retry schedule can conflict,
e.g. where we mark a bridge as "maybe up" yet we don't try to fetch
its descriptor yet, leading Tor to wait (refusing to do anything)
until it becomes time to fetch the descriptor.

Fixes bug 40497; bugfix on 0.3.0.3-alpha.
This commit is contained in:
Roger Dingledine 2021-10-23 20:32:36 -04:00
parent f9cb7e3398
commit 7084ec8710
2 changed files with 16 additions and 0 deletions

8
changes/bug40497 Normal file
View File

@ -0,0 +1,8 @@
o Minor bugfixes (bridges):
- When we don't yet have a descriptor for one of our bridges, disable
the entry guard retry schedule on that bridge. The entry guard retry
schedule and the bridge descriptor retry schedule can conflict,
e.g. where we mark a bridge as "maybe up" yet we don't try to fetch
its descriptor yet, leading Tor to wait (refusing to do anything)
until it becomes time to fetch the descriptor. Fixes bug 40497;
bugfix on 0.3.0.3-alpha.

View File

@ -2059,6 +2059,14 @@ entry_guard_consider_retry(entry_guard_t *guard)
get_retry_schedule(guard->failing_since, now, guard->is_primary);
const time_t last_attempt = guard->last_tried_to_connect;
/* Check if it is a bridge and we don't have its descriptor yet */
if (guard->bridge_addr && !guard_has_descriptor(guard)) {
/* We want to leave the retry schedule to fetch_bridge_descriptors(),
* so we don't have two retry schedules clobbering each other. See
* bugs 40396 and 40497 for details of why we need this exception. */
return;
}
if (BUG(last_attempt == 0) ||
now >= last_attempt + delay) {
/* We should mark this retriable. */