Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:49Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34446TestingTorNetwork should not set AssumeReachable 12020-06-13T15:53:49ZNick MathewsonTestingTorNetwork should not set AssumeReachable 1For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable...For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable from the chutney configurations. But that didn't actually have any effect, since `AssumeReachable 1` is implicit in `TestingTorNetwork 1`.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34445Split assumereachable into self and authority components2020-06-13T15:53:48ZNick MathewsonSplit assumereachable into self and authority componentsThis option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.This option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34069Allow extend_info to contain both IPv4 and IPv6 ORPorts2020-06-13T15:53:20ZteorAllow extend_info to contain both IPv4 and IPv6 ORPortsTo send dual-stack EXTEND2 cells in #33222, we need to have IPv4 and IPv6 addresses in extend_info_t.To send dual-stack EXTEND2 cells in #33222, we need to have IPv4 and IPv6 addresses in extend_info_t.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34068Decide how to handle control port events for IPv6 reachability self-tests2020-06-13T15:53:19ZteorDecide how to handle control port events for IPv6 reachability self-testsThe control spec has two reachability self-test events.
Here is how they are specified:
```
CHECKING_REACHABILITY
"ORADDRESS=IP:port"
"DIRADDRESS=IP:port"
We're going to start testing the reachability of our extern...The control spec has two reachability self-test events.
Here is how they are specified:
```
CHECKING_REACHABILITY
"ORADDRESS=IP:port"
"DIRADDRESS=IP:port"
We're going to start testing the reachability of our external OR port
or directory port.
REACHABILITY_SUCCEEDED
"ORADDRESS=IP:port"
"DIRADDRESS=IP:port"
We successfully verified the reachability of our external OR port or
directory port (depending on which of ORADDRESS or DIRADDRESS is
given.)
```
And here is what tor actually sends:
```
CHECKING_REACHABILITY ORADDRESS=IPv4:port
CHECKING_REACHABILITY DIRADDRESS=IPv4:port
REACHABILITY_SUCCEEDED ORADDRESS=IPv4:port
REACHABILITY_SUCCEEDED DIRADDRESS=IPv4:port
```
When we add IPv6 reachability events, we could break some (buggy) control parsers with:
```
CHECKING_REACHABILITY ORADDRESS=[IPv6]:port
REACHABILITY_SUCCEEDED ORADDRESS=[IPv6]:port
```
How should we handle this change?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34067Separate tor's IPv4 and IPv6 reachability flags2020-06-13T15:53:19ZteorSeparate tor's IPv4 and IPv6 reachability flagsIn #33222, I make tor build circuits to IPv4 and IPv6 ORPorts.
But we also need to detect IPv4 and IPv6 reachability separately.In #33222, I make tor build circuits to IPv4 and IPv6 ORPorts.
But we also need to detect IPv4 and IPv6 reachability separately.Tor: 0.4.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/34064Add an AssumeReachable consensus parameter2020-06-13T15:53:17ZteorAdd an AssumeReachable consensus parameterLike #33224, we want a network-wide consensus parameter that makes relays and bridges assume they are reachable.
We'll be modifying the IPv4 and IPv6 reachability code, so we need to be able to respond quickly to IPv4 reachability bugs ...Like #33224, we want a network-wide consensus parameter that makes relays and bridges assume they are reachable.
We'll be modifying the IPv4 and IPv6 reachability code, so we need to be able to respond quickly to IPv4 reachability bugs as well.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33918Stop truncating IPv6 addresses in channel logs2020-06-13T15:53:10ZteorStop truncating IPv6 addresses in channel logschannel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.channel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33917Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL2020-06-13T15:53:09ZteorMake IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33905Adjust "large number of connections to other relays" warnings2020-06-13T15:53:08ZteorAdjust "large number of connections to other relays" warningsIn #33880, we adjusted the limits MIN_RELAY_CONNECTIONS_TO_WARN, and the default number of connections allowed per relay.
In #33048, we will allow relays to extend via IPv6 as well as IPv4. So we should make these changes:
* warn if any...In #33880, we adjusted the limits MIN_RELAY_CONNECTIONS_TO_WARN, and the default number of connections allowed per relay.
In #33048, we will allow relays to extend via IPv6 as well as IPv4. So we should make these changes:
* warn if any relay has more than 4 connections (that is, more than 2 sides multiplied by 2 IP addresses, if there is disagreement over canonical connections).
* ignore 2 connections per relay.
Clients should only extend between two relays that support the Relay=3 protocol version. So we shouldn't need to backport this change.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33901Allow IPv6 extend cells2020-06-13T15:53:08ZteorAllow IPv6 extend cellsAs part of #33817, we want to allow IPv6 extend cells.
We want clients and relays to send:
* dual-stack EXTEND2 cells
* IPv6-only EXTEND2 cells
We want relays to parse:
* dual-stack EXTEND2 cells
* IPv6-only EXTEND2 cellsAs part of #33817, we want to allow IPv6 extend cells.
We want clients and relays to send:
* dual-stack EXTEND2 cells
* IPv6-only EXTEND2 cells
We want relays to parse:
* dual-stack EXTEND2 cells
* IPv6-only EXTEND2 cellsTor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33900Check for invalid zero IPv4 addresses and ports in extend cells2020-06-13T15:53:07ZteorCheck for invalid zero IPv4 addresses and ports in extend cellsWhen we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in #33817, I just needed a separat...When we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in #33817, I just needed a separate bug number.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33899Allow IPv6 addresses to be canonical2020-06-13T15:53:06ZteorAllow IPv6 addresses to be canonicalIn #17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This inconsisten...In #17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This inconsistency could be one cause of the logging issues in #24841.
We should allow IPv6 connections to be canonical. We should also do some cleanup of the related connection address logging in #33898.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33817Perform Basic Relay IPv6 Extends2020-06-13T15:52:51ZteorPerform 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 #33633)
[x] channel_get_for_extend() in channel.c
[x] check_extend_cell() in onion.c
[x] extend_cell_fr...Currently, tor checks that extend cells have IPv4 addresses in:
[x] some functions in circuitbuild_relay.c (a new file introduced by #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/legacy/trac/-/issues/33793Avoid some race conditions when running chutney networks in series2020-06-13T13:31:49ZteorAvoid some race conditions when running chutney networks in seriesWhen chutney runs multiple networks, one after the others, sometimes older tor instances are left running.
To avoid these issues, chutney can:
* wait longer after terminating tor processes
* cleanup pid files, so we don't accidentally t...When chutney runs multiple networks, one after the others, sometimes older tor instances are left running.
To avoid these issues, chutney can:
* wait longer after terminating tor processes
* cleanup pid files, so we don't accidentally terminate unrelated processesteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33789Before making changes, move router pick address functions to their own C file2020-06-13T15:52:45ZteorBefore 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/legacy/trac/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-06-13T15:52:40ZteorMake 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.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33679Make sure every address function that takes for_listening supports IPv62020-06-13T15:52:28ZteorMake 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/legacy/trac/-/issues/33633Move extend and reachability code to the relay module2020-06-13T15:52: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/legacy/trac/-/issues/33615Wait for at least 60 seconds for 0.3.5 and earlier to bootstrap2020-06-13T13:31:45ZteorWait for at least 60 seconds for 0.3.5 and earlier to bootstrapThe basic-min network is still a bit unstable, but only for 0.3.5. (And it's much more unrealiable on macOS than Linux.)
It seems like 0.3.5 needs around 60 seconds to bootstrap and sync descriptors. Later versions have microdescriptor ...The basic-min network is still a bit unstable, but only for 0.3.5. (And it's much more unrealiable on macOS than Linux.)
It seems like 0.3.5 needs around 60 seconds to bootstrap and sync descriptors. Later versions have microdescriptor download fixes, and they can bootstrap and verify in just over 20 seconds on basic-min.
So let's make the minimum wait time 70 seconds (3 consensuses), if any nodes in the network are running 0.3.5 (or earlier).teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33583Stop setting AssumeReachable on chutney relays and bridges2020-06-13T15:53:49ZteorStop setting AssumeReachable on chutney relays and bridgesWe need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables author...We need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables authority to relay reachability tests. (These tests are still performed on a half-hourly schedule, even in chutney networks. And they are out of scope for Sponsor 55.)
After we implement this change, we should also be able to implement #33581.teorteor