Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-07-09T17:22:52Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33880Confusing "Your relay has a very large number of connections to other relays"...2021-07-09T17:22:52ZRoger DingledineConfusing "Your relay has a very large number of connections to other relays" relay messageA new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relay...A new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relays. Found 13 current canonical connections, in 0 of which we were a
non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and
0 had more than 4 connections.
```
I checked, and their outbound address was the same as their relay address.
Upon investigation, it looks like the redundant connections are to directory authorities.
My theory is that the change from legacy/trac#17592 (which went into 0.3.1.1-alpha, commit d5a151a0) is responsible: while before that canonical relay-to-relay connections would expire after either side first reached its randomized "15 to 22.5 minute" timeout, now they expire after either side reaches its "45 to 75 minute" timeout. And since directory authorities test reachability every 1280 seconds (around 21.3 minutes), that means it is expected that most relays will have duplicate canonical connections with directory authorities.
Possible fixes:
(A) Change the notice-level log to make it clearer that it's not scary, or at least it's not actionable. Maybe that means making it info-level so nobody will see it. Probably not the best option, assuming there *are* cases where we do want relay operators to hear it.
(B) In channel_check_for_duplicates(), change `MIN_RELAY_CONNECTIONS_TO_WARN 5` to a high enough number that even if we have 2 canonical conns per authority, plus a bit more, the log message still doesn't trigger.
(C) In channel_check_for_duplicates(), skip over connections to directory authorities in some way, since we know they will be special.
(D) Make connections to or from directory authorities expire quicker, on the theory that they don't really need the same level of padding protection as other connections.
(E) Your idea here?
I'd be fine with any of B,C,D. Whichever one can be done with an easy, short, and non-invasive patch is my favorite. Maybe that's "B, raise it to 30"? That would make the message trigger when we have connections to more than 30 relays and also we have more than 45 connections open. Or we could pick the more conservative "raise it to 40", on the theory that small numbers are more likely to have edge cases and less indicative of major network problems anyway.
And while we're at it, it might be smart to say in the log message what action we want the relay operator take, e.g. "Please report:".Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33860Finish test_onionskin_answer()2021-09-16T14:21:51ZteorFinish test_onionskin_answer()In legacy/trac#33633, we finished unit tests for test_extend() and helpers.
But we didn't have time to finish test_onionskin_answer().
Let's try to test each of the cases of each `if` statement in onionskin_answer(). It's ok to mock th...In legacy/trac#33633, we finished unit tests for test_extend() and helpers.
But we didn't have time to finish test_onionskin_answer().
Let's try to test each of the cases of each `if` statement in onionskin_answer(). It's ok to mock the functions that are called by onionskin_answer().https://gitlab.torproject.org/tpo/core/tor/-/issues/33826Add a testing-only option that turns off IPv4 extends2020-07-29T14:47:13ZteorAdd a testing-only option that turns off IPv4 extendsTo test that relays perform IPv6 extends correctly, we should turn off all IPv4 extends in a test network.
The option should be called ExtendAllowIPv4Addresses, and it should be documented and implemented like ExtendAllowIPv6Addresses i...To test that relays perform IPv6 extends correctly, we should turn off all IPv4 extends in a test network.
The option should be called ExtendAllowIPv4Addresses, and it should be documented and implemented like ExtendAllowIPv6Addresses in legacy/trac#33818.
We might also need an ExtendByIPv4ORPort option, similar to ExtendByIPv6ORPort.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33819Make clients and bridges send IPv6 extends by default in Tor 0.4.52022-03-16T17:55:38ZteorMake clients and bridges send IPv6 extends by default in Tor 0.4.5If tor#33818 is included in Tor 0.4.4, the relays will send IPv6 extends by default. But clients and bridges won't, for anonymity reasons.
By the time 0.4.5 is released, a large number of clients and bridges will be on 0.4.4. So it will...If tor#33818 is included in Tor 0.4.4, the relays will send IPv6 extends by default. But clients and bridges won't, for anonymity reasons.
By the time 0.4.5 is released, a large number of clients and bridges will be on 0.4.4. So it will be safe for clients and bridge to send IPv6 extends.
Here's what we need to do to change the default:
* set `ExtendByIPv6ORPort=1` in the consensus, and
* set `ExtendByIPv6ORPort 1` as the default in Tor.
To avoid confusion, clients and bridges will send IPv6 extends, but they won't initiate outbound IPv6 connections to relays. For more details, see legacy/trac#33818 and ExtendAllowIPv6Addresses.Tor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33818Add options for clients and relays to enable IPv6 extends2022-06-16T17:57:52ZteorAdd options for clients and relays to enable IPv6 extendsTo help with testing and future network upgrades, we want to add options that:
* make clients and relays send IPv6 addresses in extend cells, and
* make relays perform extends over IPv6.
We also want to refactor the changes from legacy/...To help with testing and future network upgrades, we want to add options that:
* make clients and relays send IPv6 addresses in extend cells, and
* make relays perform extends over IPv6.
We also want to refactor the changes from legacy/trac#33817, so that we perform all the IPv6 mode checks in the same place. We want to modify tor's behaviour based on:
* tor's configuration
* including consensus parameters
* the reachability of a relay's own IPv6 ORPort, and
* any other relevant factors.
The functions that need to be refactored should all be in circuitbuild_relay.c.
We don't need to refactor or add IPv6 mode checks to the changes in legacy/trac#33899 or legacy/trac#33901. That includes these functions:
* connection_or_check_canonicity()
* channel_tls_process_netinfo_cell()
* channel_get_for_extend()
* check_extend_cell()
* extend_cell_from_extend2_cell_body()
But we might want to change how we *call* these functions from other code.
**General Options**
ExtendByIPv6ORPort (like ExtendByEd25519ID):
If this option is set to 1, Tor tries to include a relay’s IPv6 ORPort when telling the preceding relay in a circuit to extend to it. When IPv6 extends are enabled, relays and bridges use them to perform IPv6 reachability self-tests. Once these tests succeed, they publish their descriptors. (See AssumeReachable for more details.)
If this option is set to 0, Tor never includes an IPv6 ORPort when extending circuits. Tor relays and bridges are unable to perform IPv6 reachability self-tests.
If the option is set to "auto", Tor obeys a parameter in the consensus document. If the consensus parameter is not set:
* relays include IPv6 ORPorts in extend cells,
* bridges only include IPv6 ORPorts in the final extend in reachability self-test circuits,
* clients do not include IPv6 ORPorts in extend cells.
(Default: auto)
**Note:** there's a design tradeoff here:
* Gradual IPv6 upgrade:
* we can have 3 different behaviours:
* relay always sends IPv6
* bridge sends IPv6 on reachability
* client never sends IPv6
* and do a gradual IPv6 upgrade:
* stage 1: relay all, bridge reachability
* stage 2: relay, bridge, client all; or
* Big Bang IPv6 upgrade:
* we can have 2 different behaviours:
* relay, bridge sends IPv6 on reachability
* client never sends IPv6
* and do a big bang IPv6 upgrade:
* stage 1: relay and bridge reachability,
* stage 2: relay, bridge, client all
I think the gradual upgrade is less risky for the network, and the complexity of the extra code, behaviour, and testing is manageable.
**Relay and Bridge Options**
ExtendAllowIPv6Addresses (like ExtendAllowPrivateAddresses):
Relays and bridges only.
When this option is set to 1, Tor relays and bridges allow EXTEND requests to IPv6 addresses. When IPv6 extends are enabled in their own configurations, relays and bridges assume that other relays in the network will also allow IPv6 extends. So they perform IPv6 reachability self-tests, before publishing their descriptors. (See AssumeReachable for more details.)
This option does not apply to clients, or direct OR connections initiated by relays or bridges. Use ClientUseIPv6 and ClientPreferIPv6ORPort to enable direct IPv6 OR connections.
If this option is set to 0, Tor relays and bridges do not connect to IPv6 ORPorts when extending circuits. When IPv6 extends are disabled, relays and bridges assume that other relays in the network may also refuse IPv6 extends. So they continue to perform IPv6 reachability self-tests, but consider them unreliable. They publish their descriptors, regardless of the outcome of the tests.
If the option is set to "auto", Tor obeys a parameter in the consensus document. If the consensus parameter is not set:
* relays allow IPv6 extends,
* bridges do not allow IPv6 extends, and
* relays and bridges perform IPv6 reachability self-tests, before publishing their descriptors.
(Default: auto)
**Proposal Notes**
The design and option names are changed from section 4.4.4 of proposal 311, for the following reasons:
* consistent, safer design for ExtendByIPv6ORPort:
* relay reachability and other cells can't be distinguished
* relays include IPv6 first, because they don't require anonymity
* clients wait for deployment, before including IPv6 on a flag day
* bridges match clients
* ExtendAllowIPv6Addresses can wait for clients to learn IPv6
* consistency with existing options
* AssumeIPv6Reachable is no longer required, it is obsoleted by:
* AssumeReachable 1 (skip IPv4 and IPv6 reachability)
* ExtendByIPv6ORPort 0 (skip IPv6 reachability)
* ExtendAllowIPv6Addresses 0 (only log IPv6 reachability)
See:
https://github.com/torproject/torspec/blob/master/proposals/311-relay-ipv6-reachability.txt#L535https://gitlab.torproject.org/tpo/core/tor/-/issues/33817Perform Basic Relay IPv6 Extends2020-06-27T13:47:55ZteorPerform Basic Relay IPv6 ExtendsCurrently, tor checks that extend cells have IPv4 addresses in:
[x] some functions in circuitbuild_relay.c (a new file introduced by legacy/trac#33633)
[x] channel_get_for_extend() in channel.c
[x] check_extend_cell() in onion.c
[x] ext...Currently, tor checks that extend cells have IPv4 addresses in:
[x] some functions in circuitbuild_relay.c (a new file introduced by legacy/trac#33633)
[x] channel_get_for_extend() in channel.c
[x] check_extend_cell() in onion.c
[x] extend_cell_from_extend2_cell_body() in onion.c
[?] and possibly other functions.
We want to allow IPv6 in all these places.
And when we have an IPv4 and an IPv6 address, we want to choose between them at random.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33816Fill in missing IPv6 addresses in extend cells2020-10-22T15:12:33ZteorFill in missing IPv6 addresses in extend cellsWhen an extend cell is missing an IPv6 address, tor relays could use the IPv6 address from the consensus. (If there is one.)
Similarly, if the client only supplied an IPv6 address, the relay could add an IPv4 address.
Relays already ad...When an extend cell is missing an IPv6 address, tor relays could use the IPv6 address from the consensus. (If there is one.)
Similarly, if the client only supplied an IPv6 address, the relay could add an IPv4 address.
Relays already add ed25519 keys during an extend, when the client only supplies the RSA fingerprint.
This change helps obfuscate:
* whether clients know the IPv6 addresses of relays,
* which clients implement sending IPv6 addresses in extends, and
* which clients are configured to send IPv6 addresses in extends.
This change also helps with reachability, if a relay has recently gained an IPv6 ORPort, or its IPv4 ORPort is unreliable.
It has a minor impact on testing:
* increases the number of IPv6 extends, but
* decreases the number of IPv4-only extends.
This change can be made in circuit_extend():
https://github.com/torproject/tor/pull/1801/files#diff-84b529c5e46d955c02d683463cd3317bR230
By calling a function that works like circuit_extend_add_ed25519_helper(), but adds IP addresses instead:
https://github.com/torproject/tor/pull/1801/files#diff-84b529c5e46d955c02d683463cd3317bR77Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33812Add unit tests for bandwidth statistics functions2020-08-03T13:25:04ZMrSquancheeAdd unit tests for bandwidth statistics functionsWe currently don't have tests for bandwidth statistics
reporting code.
We need to write tests for the following functions.
1. commit_max()
2. advance_obs()
3. add_obs()
4. rep_hist_bandwidth_assess()
5. rep_hist_fill_bandwidth_history()
...We currently don't have tests for bandwidth statistics
reporting code.
We need to write tests for the following functions.
1. commit_max()
2. advance_obs()
3. add_obs()
4. rep_hist_bandwidth_assess()
5. rep_hist_fill_bandwidth_history()
6. rep_hist_get_bandwidth_lines()
This will be useful for legacy/trac#33617Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-27T13:47:56ZteorDefer "PreferIPv6 by default" to 0.4.4In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement ...In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since legacy/trac#32637, we have also merged:
* legacy/trac#33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* legacy/trac#32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33796socks: Prefer IPv6 by default on SOCKS port broke torsocks: re-enable a bette...2021-09-07T20:13:48ZDavid Gouletdgoulet@torproject.orgsocks: Prefer IPv6 by default on SOCKS port broke torsocks: re-enable a better version after 0.4.4?In commit `bf2a399fc0d90df76e091fa3259f7c1b8fb87781` we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.
For torsocks, this is a problem because by default it tries to re...In commit `bf2a399fc0d90df76e091fa3259f7c1b8fb87781` we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.
For torsocks, this is a problem because by default it tries to resolve an IPv4. This can be fixed _except_ when the libc call (ex: `getaddrinfo()`) is specifically requesting an IPv4 (`hints.ai_family = AF_INET`).
There is currently no way for torsocks to ask tor, via the SocksPort, a specific INET family and thus torsocks receives back the IPv6 and can't handle it because the application was expecting an IPv4.
So this example fails often as we have more and more Exits are able to resolve IPv6:
```
wget -4 some.url
```
And still many applications by default will request an IPv4 because they don't handle IPv6.
Bottom line is that torsocks use case is broken for when an application is specifically requesting an INET family...
As a reminder, torsocks can _not_ pass the hostname directly in the SOCKS connection because it hijacks libc calls and thus flow can only be 1) DNS resolution, 2) `connect()` with an IP address.
I'm not sure what to do here... I think the ideal scenario would be to have a way for our "resolve" SOCKS extension to specify an address family value.
For instance, the `F0` (`RESOLVE` command) would be "return whatever" and then we could extend to have `RESOLVE4` and `RESOLVE6`..... HACK-ish but those extensions are already a hack so...
(That prefer IPv6 change went in 043)David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33789Before making changes, move router pick address functions to their own C file2020-06-27T13:47:57ZteorBefore making changes, move router pick address functions to their own C fileAs part of Sponsor 55, let's move these relay functions to their own C files:
In src/feature/relay/resolve_addr_relay.c
* router_pick_published_address()
In src/app/config/resolve_addr.c
* resolve_my_address()
* get_last_resolved_addr(...As part of Sponsor 55, let's move these relay functions to their own C files:
In src/feature/relay/resolve_addr_relay.c
* router_pick_published_address()
In src/app/config/resolve_addr.c
* resolve_my_address()
* get_last_resolved_addr()
* reset_last_resolved_addr()
* last_resolved_addr
* is_local_addr()
* is_local_addr_impl()
These are relay-level now, but I think they should become client-level:
* router_new_address_suggestion()
* router_guess_address_from_dir_headers()
We should also move any related functions.
And write unit tests :-)Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33788Check the return value of tor_inet_ntop() and tor_inet_ntoa()2021-08-23T15:12:44ZteorCheck the return value of tor_inet_ntop() and tor_inet_ntoa()The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildc...The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildcard_check_callback()
These functions should log a bug log using BUG() or tor_assert_nonfatal(), and return an error. (Or for the formatting functions, a sensible placeholder string.)
We will also need to make their callers check for the error.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-07-09T17:42:27ZteorMake tor_inet_pton() handle bad addresses consistently on Windowstor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/p...tor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/pull/1831/commits/05f4f93722d46c0e8f1d09b4dea4bf5d1743d93f#diff-048243cd6d9ed36dda0944181d8ec8abR1729
Let's fix this bug and backport it.
In general, we should make all the functions in this file behave identically:
* zero any out parameters at the start of the function
* zero any out parameters on failureTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33681Refactor using_default_dir_authorities() local address checks2021-09-16T14:22:18ZteorRefactor using_default_dir_authorities() local address checksCurrently, we check for IPv4 and IPv6 local addresses and using_default_dir_authorities() in two different places:
* IPv4: resolve_my_address()
* IPv6: router_get_advertised_ipv6_or_ap()
Once we've combined the code that checks IPv4 and...Currently, we check for IPv4 and IPv6 local addresses and using_default_dir_authorities() in two different places:
* IPv4: resolve_my_address()
* IPv6: router_get_advertised_ipv6_or_ap()
Once we've combined the code that checks IPv4 and IPv6 advertised ORPorts, we can do a single using_default_dir_authorities() check.https://gitlab.torproject.org/tpo/core/tor/-/issues/33679Make sure every address function that takes for_listening supports IPv62020-06-27T13:48:00ZteorMake sure every address function that takes for_listening supports IPv6We need to make sure all of our basic address functions support IPv6.
For example, tor_addr_is_valid() only supports IPv4 for_listening.
We need to make this change before we create generic IPv6 listeners for proposal 312.We need to make sure all of our basic address functions support IPv6.
For example, tor_addr_is_valid() only supports IPv4 for_listening.
We need to make this change before we create generic IPv6 listeners for proposal 312.Tor: 0.4.4.x-finalMrSquancheeMrSquancheehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33633Move extend and reachability code to the relay module2021-09-16T14:22:17ZteorMove extend and reachability code to the relay moduleMost of the extend and reachability code is already in the relay module.
But some code was left behind in src/core/or/circuitbuild.c.Most of the extend and reachability code is already in the relay module.
But some code was left behind in src/core/or/circuitbuild.c.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33618Add IPv6 Support to is_local_addr()2020-06-29T14:38:48ZTracAdd IPv6 Support to is_local_addr()We propose this optional change, to improve the accuracy of IPv6 address
detection from directory documents.
Directory servers use is_local_addr() to detect if the requesting tor
instance is on the same local network. If it is, the dire...We propose this optional change, to improve the accuracy of IPv6 address
detection from directory documents.
Directory servers use is_local_addr() to detect if the requesting tor
instance is on the same local network. If it is, the directory server does
not include the X-Your-Address-Is HTTP header in directory documents.
Currently, is_local_addr() checks for:
* an internal IPv4 or IPv6 address, or
* the same IPv4 /24 as the directory server.
We propose also checking for:
* the same IPv6 /48 as the directory server.
We choose /48 because it is typically the smallest network in the global
IPv6 routing tables, and it was previously the recommended per-customer
network block. (See [RFC 6177: IPv6 End Site Address Assignment].)
Tor currently uses:
* IPv4 /8 and IPv6 /16 for port summaries,
* IPv4 /16 and IPv6 /32 for path selection (avoiding relays in the same
network block).
Source: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1099
**Trac**:
**Username**: kimimaroTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33617Add a BandwidthStatistics option and consensus parameter2022-06-17T19:10:47ZteorAdd a BandwidthStatistics option and consensus parameterStage 1:
We propose adding a new BandwidthStatistics torrc option, which activates reporting of all the bandwidth statistics. At the moment, all statistics are controlled by ExtraInfoStatistics, but we propose using the new BandwidthSt...Stage 1:
We propose adding a new BandwidthStatistics torrc option, which activates reporting of all the bandwidth statistics. At the moment, all statistics are controlled by ExtraInfoStatistics, but we propose using the new BandwidthStatistics option specifically for the bandwidth statistics.
The default value of this option should be 1. (The existing bandwidth statistics are reported by default.)
The new option should have a manual page entry, and test_parseconf.sh tests in src/test/conf_examples.
Stage 2:
Add a BandwidthStatistics consensus paramter.
Change the default value of the BandwidthStatistics option to "auto". If the value is "auto", use the value of the consensus parameter. If the consensus parameter is not set, use "1".
Update the manual page to describe the new consensus parameter.
See the proposal:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n298MrSquancheeMrSquancheehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33407Make chutney bridge authorities publish bridges in their networkstatus-bridges2020-07-20T16:07:45ZteorMake chutney bridge authorities publish bridges in their networkstatus-bridgesThis issue depends on the tor bridge descriptor upload fix in legacy/trac#33582, or robust reachability self-tests in legacy/trac#33222.
Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem,...This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582, or robust reachability self-tests in legacy/trac#33222.
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 legacy/trac#33232.
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 legacy/trac#33222 or legacy/trac#33582 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.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33375Stop advertising an IPv6 exit policy when DNS is broken for IPv62022-02-28T19:41:05ZteorStop advertising an IPv6 exit policy when DNS is broken for IPv6When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the desc...When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the descriptor, check `dns_seems_to_be_broken_for_ipv6()` before including an IPv6 exit policy
* reset `dns_seems_to_be_broken_for_ipv6()` periodically, maybe every 1-3 days?