Opened 13 months ago

Last modified 4 months ago

#28510 new defect

When relays reset bandwidth tests, the test waits until the next directory document is received

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-bwauth, 035-backport, 029-backport-maybe-not, needs-proposal, 034-unreached-backport-maybe, 033-unreached-backport-maybe
Cc: Actual Points:
Parent ID: #22453 Points:
Reviewer: Sponsor:

Description

When Tor is doing its first ORPort reachability test, it initiates one testing circuit after the first successful circuit, then one testing circuit per second until the ORPort is found reachable. Then it gives up after 20 minutes. (1200 circuits is too many.)

When tor receives any descriptor or consensus, it does another ORPort reachability test, and initiates a testing circuit.

When a testing circuit opens, and there aren't enough testing circuits to test bandwidth, then tor initiates another testing circuit.

But no testing circuits are opened after the bandwidth tests are reset.

So tor waits for the next directory document before doing a bandwidth test. We should just lunacy the tests straight away.

This is a bug on the original feature in commit 769f9201a68387c2cdf03e1efd28399c93bb2bdf in 0.1.2.2-alpha.

Child Tickets

Change History (11)

comment:1 Changed 13 months ago by teor

To fix this bug, we should call:

  • router_do_reachability_checks(1, 0) from reset_bandwidth_test()
  • router_do_reachability_checks(1, 1) from router_reset_reachability()

comment:2 Changed 13 months ago by teor

Here's a changes file:

    - Start relay bandwidth self-tests at the scheduled time, rather than
      waiting for the next directory document. Fixes bug 28510;
      bugfix on 0.1.2.2-alpha

comment:3 Changed 13 months ago by teor

Milestone: Tor: 0.4.0.x-finalTor: unspecified

We might remove the bandwidth tests after sbws is deployed.

comment:4 Changed 10 months ago by teor

These open, non-merge_ready tickets can not get backported to 0.3.3, because 0.3.3 is now unsupported.

comment:5 Changed 10 months ago by teor

Keywords: 033-backport-unreached added

Hmm, I guess they should still get 033-backport-unreached

comment:6 Changed 8 months ago by teor

Keywords: needs-proposal added

These tickets need a proposal before we write any code.

The two competing proposals in #22453 are:

  1. Remove the bandwidth self-test
  2. Increase the bandwidth self-test so it measures a reasonable amount of bandwidth

comment:7 Changed 6 months ago by nickm

Removing 034-backport from all open tickets: 034 has reached EOL.

comment:8 Changed 4 months ago by teor

Keywords: 034-unreached-backport-maybe added; 034-backport-maybe removed

0.3.4 is unsupported, we won't be backporting anything else to it.

comment:9 Changed 4 months ago by teor

Keywords: 033-unreached-backport added; 033-backport-unreached removed

Fix 033-unreached-backport spelling.

comment:10 Changed 4 months ago by teor

Keywords: 033-unreached-backport-maybe added; 033-backport-maybe removed

Remove outdated 033-backport-maybe

comment:11 Changed 4 months ago by teor

Keywords: 033-unreached-backport removed
Note: See TracTickets for help on using tickets.