Commit 7084ec87 authored by Roger Dingledine's avatar Roger Dingledine
Browse files

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.
parent f9cb7e33
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.
......@@ -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. */
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment