Make chutney bridge authorities publish bridges in their networkstatus-bridges

This issue depends on the tor bridge descriptor upload fix in #33582 (moved), or robust reachability self-tests in #33222 (moved).

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).

We can only do the networkstatus-bridges check on tor versions with the #33222 (moved) or #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.

changed milestone to %Tor: 0.4.4.x-final

Trac:
Parent Ticket: #33581 (moved)

added chutney component::core tor/tor ipv6 milestone::Tor: 0.4.4.x-final outreachy-ipv6 parent::33581 points::1 priority::medium prop311 resolution::duplicate severity::normal status::closed tor-bridge type::defect labels

Can you give us some hints about what is going wrong? That is, why the bridge authority in Chutney doesn't have any bridges in its networkstatus-bridges file?

For example, are bridges publishing to it?

The "fix bugs in" options are very broad and vague, so it is hard to pick from them yet. :)

Replying to arma:

Can you give us some hints about what is going wrong? That is, why the bridge authority in Chutney doesn't have any bridges in its networkstatus-bridges file?

For example, are bridges publishing to it?

The "fix bugs in" options are very broad and vague, so it is hard to pick from them yet. :)

I haven't done any analysis yet, I've just noticed the issue while implementing #33378 (moved) and #33379 (moved).

Once those tickets are implemented, chutney will tell me which nodes have other nodes descriptors.

One thing I can tell you is that chutney bridges have descriptors. Otherwise chutney bridge clients wouldn't be able to make any connections.

Trac:
Summary: Chutney bridge authorities have an empty networkstatus-bridges to Make chutney bridge authorities publish bridges in their networkstatus-bridges

Here are the most likely possibilities:

• Chutney bridges don't publish their descriptors to the bridge authority
  • Chutney bridges don't bootstrap
  • AssumeReachable doesn't work on bridges
  • There's something wrong with the syntax of the generated AlternateBridgeAuthority lines
  • There's some code that delays bridge descriptor posts, and TestingTorNetwork / chutney doesn't change it, or that change doesn't apply to the bridge authority
• The bridge authority has the descriptors, but it doesn't publish them in networkstatus-bridges
  • AssumeReachable doesn't work on bridge authorities
  • There's some code that delays bridge publication (like TestingAuthDirTimeToLearnReachability), and TestingTorNetwork / chutney doesn't change it, or that change doesn't apply to the bridge authority

Trac:
Keywords: N/A deleted, outreachy-ipv6 added

Trac:
Parent: #33232 (moved) to #33050 (moved)

Currently blocked by Tor's #33582 (moved) and #33408 (moved).

Trac:
Description: Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

Here are some alternative fixes:

• fix bugs in tor or chutney that stop bridges posting their descriptors to the bridge authority
• fix bugs in tor or chutney that stop the bridge authority writing bridges to the networkstatus (maybe it doesn't respect AssumeReachable?)
• grep the bridge's logs for its reachability tests

If we end up fixing tor, chutney will need to know which tor versions have these fixes (otherwise old branches will fail CI). So we may need some kind of environmental variable, tag, or version update.

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

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

Here's what we need to do:

• fix bugs in tor or chutney that stop bridges posting their descriptors to the bridge authority (#33582 (moved))
• fix bugs in tor or chutney that stop the bridge authority writing bridges to the networkstatus (maybe it doesn't respect AssumeReachable?)
• grep the bridge's logs for its reachability tests

If we end up fixing tor, chutney will need to know which tor versions have these fixes (otherwise old branches will fail CI). So we may need some kind of environmental variable, tag, or version update. (See #33408 (moved).)

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.

Here's a clearer explanation:

Currently blocked by a tor bridge bootstrap / descriptor upload race condition, see #33582 (moved).

Chutney may need to check for this tor bug fix. One way to do that is to modify the tor version EXTRA_INFO so it is sortable, see #33408 (moved).

Trac:
Description: Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

Here's what we need to do:

• fix bugs in tor or chutney that stop bridges posting their descriptors to the bridge authority (#33582 (moved))
• fix bugs in tor or chutney that stop the bridge authority writing bridges to the networkstatus (maybe it doesn't respect AssumeReachable?)
• grep the bridge's logs for its reachability tests

If we end up fixing tor, chutney will need to know which tor versions have these fixes (otherwise old branches will fail CI). So we may need some kind of environmental variable, tag, or version update. (See #33408 (moved).)

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 chutney fix is blocked by a tor bridge bootstrap / descriptor upload race condition, see #33582 (moved).

(Chutney may need to check for this tor bug fix. One way to do that is to modify the tor version EXTRA_INFO so it is sortable, see #33408 (moved).)

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

Here's what we need to do:

• fix bugs in tor or chutney that stop bridges posting their descriptors to the bridge authority (#33582 (moved))
• fix bugs in tor or chutney that stop the bridge authority writing bridges to the networkstatus (maybe it doesn't respect AssumeReachable?)
• grep the bridge's logs for its reachability tests

If we end up fixing tor, chutney will need to know which tor versions have these fixes (otherwise old branches will fail CI). So we may need some kind of environmental variable, tag, or version update. (See #33408 (moved).)

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 chutney fix is blocked by a tor bridge bootstrap / descriptor upload race condition, see #33582 (moved).

(Chutney may need to check for this tor bug fix. One way to do that is to modify the tor version EXTRA_INFO so it is sortable, see #33408 (moved).)

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

Here's what we need to do:

• fix bugs in tor or chutney that stop bridges posting their descriptors to the bridge authority (#33582 (moved))
• fix bugs in tor or chutney that stop the bridge authority writing bridges to the networkstatus (maybe it doesn't respect AssumeReachable?)
• grep the bridge's logs for its reachability tests

If we end up fixing tor, chutney will need to know which tor versions have these fixes (otherwise old branches will fail CI). So we may need some kind of environmental variable, tag, or version update. (See #33408 (moved).)

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 chutney fix is blocked by a tor bridge bootstrap / descriptor upload race condition, see #33582 (moved).

(Chutney may need to check for this tor bug fix. One way to do that is to modify the tor version EXTRA_INFO so it is sortable, see #33408 (moved).)

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

There are two different ways to fix this issue:

1. Implement the robust ORPort reachability self-tests in #33222 (moved). Bridges bootstrap, self-test reachability, and then publish their descriptors.

2. Make bridge descriptor upload wait until the bridge has bootstrapped in #33582 (moved). Bridges bootstrap, then publish their descriptors.

Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).

We can only do the networkstatus-bridges check on tor versions with the #33222 (moved) or #33582 (moved) fixes. If we want to do these tests before an 0.4.4-alpha release, we can:

• implement ordered version EXTRA_INFO in #33408 (moved),
• check for a log message that we add to tor during the fix, or
• set an environmental variable.

Whatever we do, we should also check for the next 0.4.4-alpha release, so we don't depend on these implementation details.

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.

Instead of this fix, we can make chutney check tor's logs for reachability self-test successes. See #34037 (moved).

Trac:
Description: This chutney fix is blocked by a tor bridge bootstrap / descriptor upload race condition, see #33582 (moved).

(Chutney may need to check for this tor bug fix. One way to do that is to modify the tor version EXTRA_INFO so it is sortable, see #33408 (moved).)

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

There are two different ways to fix this issue:

1. Implement the robust ORPort reachability self-tests in #33222 (moved). Bridges bootstrap, self-test reachability, and then publish their descriptors.

2. Make bridge descriptor upload wait until the bridge has bootstrapped in #33582 (moved). Bridges bootstrap, then publish their descriptors.

Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).

We can only do the networkstatus-bridges check on tor versions with the #33222 (moved) or #33582 (moved) fixes. If we want to do these tests before an 0.4.4-alpha release, we can:

• implement ordered version EXTRA_INFO in #33408 (moved),
• check for a log message that we add to tor during the fix, or
• set an environmental variable.

Whatever we do, we should also check for the next 0.4.4-alpha release, so we don't depend on these implementation details.

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

Instead of this fix, we can make chutney check tor's logs for reachability self-test successes. See #34037 (moved).

This chutney fix also needs fixes to a tor bridge descriptor upload race condition, see #33582 (moved).

(Chutney may need to check for this tor bug fix. One way to do that is to modify the tor version EXTRA_INFO so it is sortable, see #33408 (moved).)

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

There are two different ways to fix this issue:

1. Implement the robust ORPort reachability self-tests in #33222 (moved). Bridges bootstrap, self-test reachability, and then publish their descriptors.

2. Make bridge descriptor upload wait until the bridge has bootstrapped in #33582 (moved). Bridges bootstrap, then publish their descriptors.

Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).

We can only do the networkstatus-bridges check on tor versions with the #33222 (moved) or #33582 (moved) fixes. If we want to do these tests before an 0.4.4-alpha release, we can:

• implement ordered version EXTRA_INFO in #33408 (moved),
• check for a log message that we add to tor during the fix, or
• set an environmental variable.

Whatever we do, we should also check for the next 0.4.4-alpha release, so we don't depend on these implementation details.

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:
Parent: #33050 (moved) to #33581 (moved)

This is now a duplicate of #33581 (moved). I don't think there's any issue with the bridge authority or chutney, it's probably just a tor bug.

Trac:
Status: new to closed
Description: Instead of this fix, we can make chutney check tor's logs for reachability self-test successes. See #34037 (moved).

This chutney fix also needs fixes to a tor bridge descriptor upload race condition, see #33582 (moved).

(Chutney may need to check for this tor bug fix. One way to do that is to modify the tor version EXTRA_INFO so it is sortable, see #33408 (moved).)

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

There are two different ways to fix this issue:

1. Implement the robust ORPort reachability self-tests in #33222 (moved). Bridges bootstrap, self-test reachability, and then publish their descriptors.

2. Make bridge descriptor upload wait until the bridge has bootstrapped in #33582 (moved). Bridges bootstrap, then publish their descriptors.

Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).

We can only do the networkstatus-bridges check on tor versions with the #33222 (moved) or #33582 (moved) fixes. If we want to do these tests before an 0.4.4-alpha release, we can:

• implement ordered version EXTRA_INFO in #33408 (moved),
• check for a log message that we add to tor during the fix, or
• set an environmental variable.

Whatever we do, we should also check for the next 0.4.4-alpha release, so we don't depend on these implementation details.

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 #33582 (moved), or robust reachability self-tests in #33222 (moved).

Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232 (moved).

Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).

We can only do the networkstatus-bridges check on tor versions with the #33222 (moved) or #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.
Resolution: N/A to duplicate

Trac:
Sponsor: Sponsor55-can to N/A

closed

changed time estimate to 8h

mentioned in issue #33408 (moved)

mentioned in issue #34037 (moved)

mentioned in issue #33581 (moved)

mentioned in issue tpo/core/chutney#33228 (closed)

moved to tpo/core/tor#33407 (closed)

mentioned in issue tpo/core/tor#33408 (closed)