Opened 9 years ago

Last modified 3 years ago

#3322 new defect

We don't retry our bridges if we have an unconfigured bridge that's up

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-bridge tor-guards prop271 sponsor8-maybe bootstrap
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


If we start with a bridge X but then setconf to bridge Y, and then Y fails a circuit at the first hop, we mark Y down. When we get a new stream, we should be optimistically retrying our bridges, but we're not because X is still up.

Related to #3321.

Child Tickets

Change History (6)

comment:1 Changed 9 years ago by arma

The issue is that circuit_get_open_circ_or_launch() checks

      if (entry_list_is_constrained(options) &&
          entries_known_but_down(options)) {

where entries_known_but_down() calls entries_retry_helper(options, 0) which checks

  int purpose = options->UseBridges ?
      ri = router_get_by_digest(e->identity);
      if (ri && ri->purpose == purpose) {
        any_known = 1;

Basically, it doesn't care if the bridge is currently in our Bridge config list, so long as there is some descriptor we know that has purpose bridge.

The right answer here is to replace all of this with a call to entry_is_live(e). But I worry that a down entry isn't live (because it's "bad"), so we wouldn't find it.

The interim (0.2.2.x) fix might be to just check explicitly if it's a configured bridge.

comment:2 Changed 9 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

comment:3 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:4 Changed 8 years ago by nickm

Keywords: tor-bridge added

comment:5 Changed 8 years ago by nickm

Component: Tor BridgeTor

comment:6 Changed 3 years ago by nickm

Keywords: tor-guards prop271 sponsor8-maybe bootstrap added
Severity: Normal
Note: See TracTickets for help on using tickets.