Restore bridge networkstatus checks in chutney
This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), robust reachability self-tests in legacy/trac#33222 (moved), or bridge log checks in legacy/trac#34037 (moved).
In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Also, the chutney workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.
Activity
Trac:
Parent Ticket: legacy/trac#33582 (moved)
Child Ticket(s): legacy/trac#33407 (moved)added component::core tor/chutney in Legacy / Trac ipv6 in Legacy / Trac parent::33582 in Legacy / Trac points::0.1 in Legacy / Trac priority::medium in Legacy / Trac prop311 in Legacy / Trac severity::normal in Legacy / Trac sponsor::55-can in Legacy / Trac status::new in Legacy / Trac type::defect in Legacy / Trac labels
Trac:
Description: In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:- bridges have AssumeReachable set
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
Once we make bridges do reachability checks in chutney, they will wait to bootstrap, do reachability checks, then try to publish their descriptors.
So we can enable the bridge networkstatus checks again.
to
In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges have AssumeReachable set
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
Once we fix legacy/trac#33582 (moved), we can fix this issue.
Trac:
Parent: legacy/trac#33232 (moved) to legacy/trac#33582 (moved)Trac:
Description: In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:- bridges have AssumeReachable set
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
Once we fix legacy/trac#33582 (moved), we can fix this issue.
to
This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), or robust reachability self-tests in legacy/trac#33222 (moved).
In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges have AssumeReachable set
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Trac:
Description: This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), or robust reachability self-tests in legacy/trac#33222 (moved).In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges have AssumeReachable set
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
to
This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), or robust reachability self-tests in legacy/trac#33222 (moved).
In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges have AssumeReachable set
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Also, the chutney workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.
AssumeReachable isn't required to trigger this issue.
Trac:
Description: This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), or robust reachability self-tests in legacy/trac#33222 (moved).In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges have AssumeReachable set
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Also, the chutney workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.
to
This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), or robust reachability self-tests in legacy/trac#33222 (moved).
In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Also, the chutney workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.
Trac:
Description: This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), or robust reachability self-tests in legacy/trac#33222 (moved).In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Also, the chutney workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.
to
This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582 (moved), robust reachability self-tests in legacy/trac#33222 (moved), or bridge log checks in legacy/trac#34037 (moved).
In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
- bridges try to publish their descriptors before bootstrapping
- but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 (moved) or legacy/trac#33582 (moved) fixes. So we'll need to check for:
- the next tor 0.4.4-alpha version, or
- an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Also, the chutney workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.
mentioned in issue legacy/trac#33583 (moved)
mentioned in issue legacy/trac#33407 (moved)
mentioned in issue legacy/trac#33582 (moved)
moved from legacy/trac#33581 (moved)
added Bug label and removed 1 deleted label
added IPv6 label and removed 1 deleted label
mentioned in issue #40005 (closed)
I've used Chutney's new-ish launch-phase feature to make it so we bootstrap authorities before bridges before clients. This has let me revert the change that turned off this check, in #40005 (closed) and !4 (merged)