commit 97249c4f5e389141cb4ff3562a3813bd09bff6ad Author: teor teor2345@gmail.com Date: Tue Aug 29 14:04:24 2017 +1000
Make bridge clients download bridge descriptors immediately
The download schedule tells Tor to wait 15 minutes before downloading bridge descriptors. But 17750 made Tor ignore that and start immediately. Since we fixed 17750, Tor waits 15 minutes for bridge client bootstrap, like the schedule says.
This fixes the download schedule to start immediately, and to try each bridge 3 times in the first 30 seconds. This should make bridge bootstraps more reliable.
Fixes 23347. --- changes/bug23347 | 6 ++++++ doc/tor.1.txt | 5 +++-- src/or/bridges.c | 11 +++++++++-- src/or/config.c | 9 +++++++-- src/or/directory.c | 4 ++-- 5 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/changes/bug23347 b/changes/bug23347 new file mode 100644 index 000000000..b0883784d --- /dev/null +++ b/changes/bug23347 @@ -0,0 +1,6 @@ + o Minor bug fixes (bridge client bootstrap): + - Make bridge clients download bridge descriptors immediately. + The bridge schedules were never correct, but we didn't realise until + the fix for 17750 made bridge clients hang for 15 minutes before + bootstrapping. + Fixes bug 23347. Not in any released version of Tor. diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 9949f9dd0..e3939d115 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -2475,7 +2475,7 @@ The following options are used for running a testing Tor network. TestingClientDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60 TestingServerConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60 TestingClientConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60 - TestingBridgeDownloadSchedule 60, 30, 30, 60 + TestingBridgeDownloadSchedule 0, 5, 10, 30, 60 TestingClientMaxIntervalWithoutRequest 5 seconds TestingDirConnectionMaxStall 30 seconds TestingConsensusMaxDownloadTries 80 @@ -2541,7 +2541,8 @@ The following options are used for running a testing Tor network.
[[TestingBridgeDownloadSchedule]] **TestingBridgeDownloadSchedule** __N__,__N__,__...__:: Schedule for when clients should download bridge descriptors. Changing this - requires that **TestingTorNetwork** is set. (Default: 1200, 900, 900, 3600) + requires that **TestingTorNetwork** is set. (Default: 0, 8, 3600, 10800, + 25200, 54000, 111600, 262800)
[[TestingClientMaxIntervalWithoutRequest]] **TestingClientMaxIntervalWithoutRequest** __N__ **seconds**|**minutes**:: When directory clients have only a few descriptors to request, they batch diff --git a/src/or/bridges.c b/src/or/bridges.c index 0818fb081..f2244004f 100644 --- a/src/or/bridges.c +++ b/src/or/bridges.c @@ -632,7 +632,9 @@ fetch_bridge_descriptors(const or_options_t *options, time_t now) continue; }
- /* schedule another fetch as if this one will fail, in case it does */ + /* schedule another fetch as if this one will fail, in case it does + * (we can't increment after a failure, because sometimes we use the + * bridge authority, and sometimes we use the bridge direct) */ download_status_failed(&bridge->fetch_status, 0);
can_use_bridge_authority = !tor_digest_is_zero(bridge->identity) && @@ -787,8 +789,13 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache) if (bridge) { /* if we actually want to use this one */ node_t *node; /* it's here; schedule its re-fetch for a long time from now. */ - if (!from_cache) + if (!from_cache) { download_status_reset(&bridge->fetch_status); + /* We have two quick attempts in the bridge schedule, and then slow + * ones */ + download_status_failed(&bridge->fetch_status, 0); + download_status_failed(&bridge->fetch_status, 0); + }
node = node_get_mutable_by_id(ri->cache_info.identity_digest); tor_assert(node); diff --git a/src/or/config.c b/src/or/config.c index 30853724e..54df6c3e5 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -586,7 +586,10 @@ static config_var_t option_vars_[] = { * blackholed. Clients will try 3 directories simultaneously. * (Relays never use simultaneous connections.) */ V(ClientBootstrapConsensusMaxInProgressTries, UINT, "3"), - V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "1200, 900, 900, 3600"), + /* The bridge code relies on the third item in this schedule being slow + * (~ 1 consensus interval) */ + V(TestingBridgeDownloadSchedule, CSV_INTERVAL, + "0, 8, 3600, 10800, 25200, 54000, 111600, 262800"), V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "10 minutes"), V(TestingDirConnectionMaxStall, INTERVAL, "5 minutes"), V(TestingConsensusMaxDownloadTries, UINT, "8"), @@ -648,7 +651,9 @@ static const config_var_t testing_tor_network_defaults[] = { "15, 20, 30, 60"), V(TestingClientConsensusDownloadSchedule, CSV_INTERVAL, "0, 0, 5, 10, " "15, 20, 30, 60"), - V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "60, 30, 30, 60"), + /* The bridge code relies on the third item in this schedule being slow + * (~ 1 consensus interval) */ + V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "0, 5, 10, 30, 60"), V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "5 seconds"), V(TestingDirConnectionMaxStall, INTERVAL, "30 seconds"), V(TestingConsensusMaxDownloadTries, UINT, "80"), diff --git a/src/or/directory.c b/src/or/directory.c index 57dfdd9ca..6b5e16bfd 100644 --- a/src/or/directory.c +++ b/src/or/directory.c @@ -5663,8 +5663,8 @@ download_status_get_initial_delay_from_now(const download_status_t *dls) * (We find the zeroth element of the download schedule, and set * next_attempt_at to be the appropriate offset from 'now'. In most * cases this means setting it to 'now', so the item will be immediately - * downloadable; in the case of bridge descriptors, the zeroth element - * is an hour from now.) */ + * downloadable; when using authorities with fallbacks, there is a few seconds' + * delay.) */ void download_status_reset(download_status_t *dls) {