onion-tunnel: Stricter bootstrap recognition
This commit makes the onion-tunnel bootstrapping more conservative in when to be considered bootstrapped.
Previously, there has been a tokio timeout task that gave the
TorClient::bootstrap method a 30 second chance to complete, before
indicating an error.
This works well in a censored environment where the user has never been able to download any sort of consensus, because in that case, arti will obviously be unable to fetch one, so the bootstrap method will time out.
However, when the user happens to have a valid consensus in their cache, the bootstrap call will succeed immediately, even though arti may in fact not be usable.
To mitigate this issue, we add a loop after the bootstrap call, which
will terminate only if it receives at least one bootstrap status
indicating a usability of the Tor network.
See #110
Merge request reports
Activity
requested review from @ahf
cc @cyberta
mentioned in issue #110
421 // 422 // We considere arti to be bootstrapped iff the bootstrap() method succeeds *and* there has been 423 // at least one `ConnStatus` implying usability. 424 // 425 // TODO(cve): Keep in mind that ConnStatus may theoretically get unbootstrapped and work in a 426 // non monotone fashion, this approach sort of ignores this. 421 427 let mut bootstrap_task = Box::pin( 422 428 tokio::time::timeout( 423 429 // TODO: Might worth adding this as a config parameter? 424 430 std::time::Duration::new(30, 0), 425 tokio::spawn(async move { tc.bootstrap().await }), 431 tokio::spawn(async move { 432 tc.bootstrap().await?; 433 let mut events = tc.chanmgr().bootstrap_events(); 434 while let Some(status) = events.next().await { 435 if status.usable() { 
418 418 // We'll give arti 30 seconds to bootstrap. The following is some Rust ninjitstu for the 419 419 // timeout task to be used in the select below and fused so once completed, it is basically 420 420 // ignored while still being polled. 421 // 422 // We considere arti to be bootstrapped iff the bootstrap() method succeeds *and* there has been changed this line in version 2 of the diff
-
Sorry for asking maybe sth. obvious, but - what effect does this change have on the caching mechanism in general? What is caching still used for? Does the early failure allow the user to configure bridges and reconnect with the help of the cached consensus?
Edited by cyberta -
It doesn't change the caching mechanism in general really. This is mostly because its a low-level arti internal. (I think it is part of the tor-dirmgr crate).
IIRC caching is used to not overload the directory authorities and the mirrors. They already need to spend a high amount of bandwidth for offering this information.
The torrc even mentions this:
## Uncomment this to mirror directory information for others. Please do ## if you have enough bandwidth. #DirPort 9030 # what port to advertise for directory connectionsEdited by Clara Engler
added 1 commit
- e71cadb4 - onion-tunnel: Stricter bootstrap recognition
enabled an automatic merge when all merge checks for e71cadb4 pass
mentioned in commit 75071fd4