Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-07-21T15:54:06Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40052S55: Make router_has_advertised_ipv6_orport() look at the descriptor2020-07-21T15:54:06ZNick MathewsonS55: Make router_has_advertised_ipv6_orport() look at the descriptorRight now, `router_has_advertised_ipv6_orport()` only looks at the configured advertised ports, and doesn't look at whether we have a published ORPort. That's not what we want it to do; we should look at the descriptor we're publishing,...Right now, `router_has_advertised_ipv6_orport()` only looks at the configured advertised ports, and doesn't look at whether we have a published ORPort. That's not what we want it to do; we should look at the descriptor we're publishing, I think.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40043relay: Stop using uint32_t addr for IPv4 and move to tor_addr_t2020-07-14T14:45:51ZDavid Gouletdgoulet@torproject.orgrelay: Stop using uint32_t addr for IPv4 and move to tor_addr_tThis is actually pretty big change. Originally, I planned to have it part of tor#40025 but it turns out quite a diff.
The goal is to stop using `uint32_t addr` to represent an IPv4 address and inste
ad standardize it onto `tor_addr_t` s...This is actually pretty big change. Originally, I planned to have it part of tor#40025 but it turns out quite a diff.
The goal is to stop using `uint32_t addr` to represent an IPv4 address and inste
ad standardize it onto `tor_addr_t` so the IPv4 and IPv6 interface are the same.
So many places in the code we convert from `ipv4{h|n}` to `tor_addr_t`, it is not pretty so this ticket is to move every use of those for relay objects (ri, rs, md, etc...).Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40039ipv6: Specialize GETINFO address interface for v4 and v62020-08-10T18:51:26ZDavid Gouletdgoulet@torproject.orgipv6: Specialize GETINFO address interface for v4 and v6We require a way for the control port `GETINFO address` command to also return the IPv6.
We propose to specialize the interface with:
`GETINFO address/v4`
`GETINFO address/v6`
And that `address` alone returns the IPv4 or IPv6 if no v4...We require a way for the control port `GETINFO address` command to also return the IPv6.
We propose to specialize the interface with:
`GETINFO address/v4`
`GETINFO address/v6`
And that `address` alone returns the IPv4 or IPv6 if no v4 can be found which basically retain its current behavior of returning the main IPv4 address.Tor: 0.4.5.x-freezeNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40025Prop 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptor2020-07-21T12:04:11ZDavid Gouletdgoulet@torproject.orgProp 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptorAt the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a direct...At the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a directory server suggested us.
With the work in tor#40022, we now discover our address with the `NETINFO` cell for both IPv4 and IPv6. We should use that.
Thus this ticket means that we need a new interface to query "what address should I use in my descriptor" so it is usable per address family and queries the right caches (that is not the directory guessed IP cache anymore).Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40022Prop 312: Relay learn address from NETINFO cell2020-07-14T18:17:12ZDavid Gouletdgoulet@torproject.orgProp 312: Relay learn address from NETINFO cellRelays do not currently use any address information from NETINFO cells.
We should try to learn our address for relays and possibly using `router_new_address_suggestion()` to do so.Relays do not currently use any address information from NETINFO cells.
We should try to learn our address for relays and possibly using `router_new_address_suggestion()` to do so.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34412Additonal unit tests for functions related to ipv6 self-test2020-10-22T15:12:33ZNick MathewsonAdditonal unit tests for functions related to ipv6 self-testSee legacy/trac#33222 and legacy/trac#34200 for lists of functions that did not get unit tests as part of the legacy/trac#34200 merge.See legacy/trac#33222 and legacy/trac#34200 for lists of functions that did not get unit tests as part of the legacy/trac#34200 merge.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34200Refactor tor's circuit path node selection checks2022-07-11T12:31:51ZteorRefactor tor's circuit path node selection checksIn legacy/trac#33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.In legacy/trac#33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34167PublishServerDescriptor via IPv62020-07-29T14:55:17ZTracPublishServerDescriptor via IPv6let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifi...let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifies how descriptors Tor will publish when acting as
# a relay. You can
# choose multiple arguments, separated by commas.
#
# If this option is set to 4, Tor will publish its
# descriptors to any directories over IPv4. (This is useful if you're not IPv6 connectable
# out your server, or if you're using a IPv6 Translation Tunnel)
# Otherwise, Tor will publish its
# descriptors via IPv6. The default is "auto", which
# means "if running as a relay or bridge, publish descriptors to the
# appropriate authorities over what's reachable". Other possibilities are "or", meaning
# "publish as if you're a OnionService", "publish over onion circuit".
```
_may Sponsor55 or prop311-prop313 already covered if i missed or could be relevant for_
**Trac**:
**Username**: ϲypherpunksTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34137Make sure inform_testing_reachability() reports the correct ports2021-09-16T14:21:52ZteorMake sure inform_testing_reachability() reports the correct portsIn legacy/trac#33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass fla...In legacy/trac#33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that it logs the actual reachability tests that are being run. (Rather than re-checking the relay's own routerinfo, which may have changed since the most recent reachability checks were launched.)
But inform_testing_reachability() is called when:
* the first circuit finishes building, or
* tor is reconfigured, and some circuits have already finished building.
So we need to do a bit of a refactor.
The refactor should preserve this behaviour:
* don't log until after the first circuit has finished building (rather than logging as soon as we start building reachability circuits)
And introduce this new behaviour:
* log the ports that were tested recently, rather than the ports that are currently available.
As an alternative, we could move some of the logging into the functions that actually launch the checks. And elevate some of those logs to notice level. (Note that these checks can be launched from at least 4 different locations in tor's code.)Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34069Allow extend_info to contain both IPv4 and IPv6 ORPorts2020-10-22T15:12:33ZteorAllow extend_info to contain both IPv4 and IPv6 ORPortsTo send dual-stack EXTEND2 cells in legacy/trac#33222, we need to have IPv4 and IPv6 addresses in extend_info_t.To send dual-stack EXTEND2 cells in legacy/trac#33222, we need to have IPv4 and IPv6 addresses in extend_info_t.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34068Decide how to handle control port events for IPv6 reachability self-tests2020-10-22T15:12:32ZteorDecide 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?David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34067Separate tor's IPv4 and IPv6 reachability flags2020-10-22T15:12:33ZteorSeparate tor's IPv4 and IPv6 reachability flagsIn legacy/trac#33222, I make tor build circuits to IPv4 and IPv6 ORPorts.
But we also need to detect IPv4 and IPv6 reachability separately.In legacy/trac#33222, I make tor build circuits to IPv4 and IPv6 ORPorts.
But we also need to detect IPv4 and IPv6 reachability separately.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34065Make routerset_contains_router() support IPv62020-10-22T15:12:33ZteorMake routerset_contains_router() support IPv6In router_should_check_reachability(), we test to see if the current relay is in ExcludeNodes.
But ExcludeNodes doesn't support IPv6, so if a user excludes our IPv6 address, we'll just ignore that setting.
This is not a required task.
...In router_should_check_reachability(), we test to see if the current relay is in ExcludeNodes.
But ExcludeNodes doesn't support IPv6, so if a user excludes our IPv6 address, we'll just ignore that setting.
This is not a required task.
But we should probably be explicit about ignoring IPv6 in the man page.Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33919Write unit tests for channel_matches_target_addr_for_extend()2021-09-16T14:21:51ZteorWrite unit tests for channel_matches_target_addr_for_extend()In legacy/trac#33817, we modify channel_matches_target_addr_for_extend() to take an IPv4 and an IPv6 address.
We also modify channel_get_for_extend() to take an IPv4 and an IPv6 address. It has existing tests, but they ignore IP address...In legacy/trac#33817, we modify channel_matches_target_addr_for_extend() to take an IPv4 and an IPv6 address.
We also modify channel_get_for_extend() to take an IPv4 and an IPv6 address. It has existing tests, but they ignore IP addresses. (And mock the matches_target() method, which is called by channel_matches_target_addr_for_extend().)
It would be useful to have tests that check that a channel matches, if its IP address matches the IPv4 or IPv6 address. But it's not urgent. (And the actual changes to the function are pretty trivial.)
The setup for these tasks is a bit tricky, we need to set up a channel_tls_t and an associated connection_t with a real_addr. (Note that legacy/trac#33898 may change the name of real_addr.)
This task is not urgent or important. Anyone can do this task.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33918Stop truncating IPv6 addresses in channel logs2020-06-27T13:47:52ZteorStop 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/tpo/core/tor/-/issues/33917Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL2021-09-16T14:21:51ZteorMake 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/tpo/core/tor/-/issues/33901Allow IPv6 extend cells2020-06-27T13:47:52ZteorAllow IPv6 extend cellsAs part of legacy/trac#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 legacy/trac#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/tpo/core/tor/-/issues/33900Check for invalid zero IPv4 addresses and ports in extend cells2021-09-16T14:21:51ZteorCheck 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 legacy/trac#33817, I just neede...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 legacy/trac#33817, I just needed a separate bug number.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33899Allow IPv6 addresses to be canonical2020-06-27T13:47:53ZteorAllow IPv6 addresses to be canonicalIn legacy/trac#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 ...In legacy/trac#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 legacy/trac#24841.
We should allow IPv6 connections to be canonical. We should also do some cleanup of the related connection address logging in legacy/trac#33898.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33898Stop modifying addr on connections, and delete real_addr2021-09-16T14:21:51ZteorStop modifying addr on connections, and delete real_addrIn connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remo...In connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remote peer. And for some reason, we also have conn.address, a string copy of the peer's canonical address and port.
See:
https://github.com/torproject/tor/blob/7f9eaec538b7d01e0d1b130dc4cf2ec634252d46/src/core/or/connection_or.c#L920
This is... a mess.
Here's the high-level interface I'd like to see:
* use a function to format a connection or channel addresses for loogging
* use exactly as many address and port variables as needed in connection and channel (no extras!)
* qualify each address and port variable's name with its purpose
For example, here's one possible design:
* delete addr, port, address, and real_addr
* add remote_ap, a tor_addr_port_t that is the remote address and port of the TCP connection to the remote peer
* implement connection_describe(), which:
* formats remote_ap,
* formats is_canonical (and any other useful info), and
* calls node_describe() to format the canonical IPv4 and IPv6 addresses and ports of the remote peer.
We may also need separate fields for reverse proxied addresses, see the comment at:
https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339
If we need separate variables or functions for channels, we can use a similar design. (But ideally, re-using as many functions and variables as possible.)
This is important for Sponsor 55: getting accurate connection information will make diagnosing bugs much easier.
Current subtasks:
* [x] #40040 Document behavior of addr/address/real_addr fields
* [x] #40041 Add "describe connection" and "describe peer" functions.
* [ ] #40042 Give `or_connection_t` "canonical addr" instead of "real addr"Nick MathewsonNick Mathewson