Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-07-09T17:22:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6939Missing IPv6 ORPort reachability check2021-07-09T17:22:51ZshamrockMissing IPv6 ORPort reachability checkIssue:
Tor does not log (or does not perform) a test to determine if an IPv6 ORPort is reachable.
Tor does log a corresponding test for an IPv4 ORPort.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (git-05...Issue:
Tor does not log (or does not perform) a test to determine if an IPv6 ORPort is reachable.
Tor does log a corresponding test for an IPv4 ORPort.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (git-0537dc6364594474)
How to reproduce:
- configure Tor with both IPv4 and IPv6 IP addresses and OrPorts.
- start Tor
- the Tor log file will show a test to determine if the IPv4 OrPort is reachable, but not if the IPv6 ORPort is reachable.
- (this particular system was configured as a bridge)
Expected Behavior:
The user might expect to see a log entry for IPv6 that corresponds to the following log entry for IPv4:
"Sep 22 11:09:21.000 [notice] Now checking whether ORPort [host's IPv4 address]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)"Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25295Torsocks only accepts IPv4 replies but Tor prefers IPv6Automap by default2021-07-05T17:47:56ZTracTorsocks only accepts IPv4 replies but Tor prefers IPv6Automap by defaultAt the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer...At the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:681)` when tor replies with an IPv6 address, which it does every single time for mapaddress .exit entries for me.
**Trac**:
**Username**: fuzzyTewTor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/29243Fix minor bugs in the HSv3 unit tests2021-06-23T17:26:03ZteorFix minor bugs in the HSv3 unit testsThe tests:
* copy the first 20 characters of a 40-character hex string to a binary fingerprint
* put IPv6 addresses in a variable called "ipv4"
* do a duplicate tt_int_op() to deliberately fail and print a value, without a comment explai...The tests:
* copy the first 20 characters of a 40-character hex string to a binary fingerprint
* put IPv6 addresses in a variable called "ipv4"
* do a duplicate tt_int_op() to deliberately fail and print a value, without a comment explaining the code
Let's review these changes in legacy/trac#23576.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29237Restore IPv6 intro points in the HS client tests2021-06-23T17:26:03ZteorRestore IPv6 intro points in the HS client testsIn legacy/trac#23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.In legacy/trac#23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31492Update hsv3 spec for unreachable/failed single onion retries using 3 hops2021-06-23T17:24:15ZteorUpdate hsv3 spec for unreachable/failed single onion retries using 3 hopsThis ticket is the spec part of legacy/trac#23818, legacy/trac#23507, and legacy/trac#23588.This ticket is the spec part of legacy/trac#23818, legacy/trac#23507, and legacy/trac#23588.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32141single onion v3 IPv6 intro circuit BUG() warnings2021-06-23T17:23:06Zteorsingle onion v3 IPv6 intro circuit BUG() warningsLooks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) fail...Looks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at src/feature/hs/hs_client.c:491. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at src/feature/hs/hs_client.c:685. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:491: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:685: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
```
https://travis-ci.org/torproject/tor/jobs/599435523#L3431Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/4806Detect and warn when running IPv6-using client without IPv6 address privacy2021-06-18T18:25:22ZNick MathewsonDetect and warn when running IPv6-using client without IPv6 address privacyLots of IPv6 implementations default to deriving the last 48 bits of the address from local host's ethernet MAC address. There's an optional, usually-off-by-default feature that randomizes addresses for outbound connections (see RFC 494...Lots of IPv6 implementations default to deriving the last 48 bits of the address from local host's ethernet MAC address. There's an optional, usually-off-by-default feature that randomizes addresses for outbound connections (see RFC 4941), but not all clients will know where it is, or know how to turn it on.
That's problematic for users on laptops or other mobile devices, since their MAC address provides a way to tell it's still them as they move around the network.
Perhaps when Tor is running as a client, we should detect whether the address(es) we're using on outbound connections match any MAC address, and warn if so. (Without root, we can't do more than warn and suggest a workaround.)
On Windows, it's part of the info we get from GetAdaptersAddresses(). On Linux and OSX this info *seems* to be available via getifaddrs(): we just need to check for AF_PACKET addresses on Linux and AF_LINK addresses on Mac. BSDs seem to do the same thing as OSX here.
Failing that, on Linux, we can learn the MAC address of a socket with ioctl(SIOCGIFHWADDR). On OSX, it looks like we might need to mess around with the IOKit framework and a chain of twisty little calls that start with IOServiceMatching and end no place good.
We'll need to suggest some action for the user to take. For a relay, no action is necessary. For a bridge, I'm not too sure. For a client, the OSX and FreeBSD fix appears to be "sysctl -w net.inet6.ip6.use_tempaddr=1 " ; On Linux, it's maybe "sysctl net.ip6.conf.if.use_tempaddr=2". On Windows, it's probably somthing fiddly.https://gitlab.torproject.org/tpo/core/tor/-/issues/11360Listen on IPv6 by default for SocksPort *:Port2021-06-18T18:20:31ZDavid Gouletdgoulet@torproject.orgListen on IPv6 by default for SocksPort *:PortThat would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon....That would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon.
One way to fix that would be to change the function parse_port_config() in _src/or/config.c_ to allow multiple default values adding v6 defaults (which would benefit other ports as well).
Else, having a check somewhere that adds other defaults for specific ports but not sure that it's a good idea nor makes sense in the long run in terms of maintainability.
I thought also about bringing back legacy/trac#4760 by default and setting the ipv6 only option only and only if the user has defined an option in the torrc explicitly. For instance, this in the torrc would ONLY allow v6 (remove dual stack).
```
SocksPort [::1]:9050
```
Thoughts?https://gitlab.torproject.org/tpo/core/tor/-/issues/40296Reverse DNS IPv6 issue?2021-03-23T12:19:46Zh3nkdet3nkReverse DNS IPv6 issue?Not sure if this is related to #40288, but since version 0.4.5.6 I experienced an issue with my Tor relay node not being published.
Received following log warning:
```
Feb 16 03:15:56.000 [warn] The IPv6 ORPort address xxx::bff does no...Not sure if this is related to #40288, but since version 0.4.5.6 I experienced an issue with my Tor relay node not being published.
Received following log warning:
```
Feb 16 03:15:56.000 [warn] The IPv6 ORPort address xxx::bff does not match the descriptor address xxx::bef. If you have a static public IPv4 address, use 'Address <IPv6>' and 'OutboundBindAddress <IPv6>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
```
However, my ORPort published in torrc config is:
`ORPort [x::bff]:43261`
It is being caused by my reverse DNS on IPv4, which resolves to my domain.
If AAAA for my domain is looked up on it returns the ":bef" address. I fixed this by changing AAAA record for my domain AAAA record to ":bff". Somehow the "auto-detect" feature is looking up reverse DNS and checking the corresponding AAAA record for the domain I guess.
Is this a bug or should I make configuration changes? I would like to be able to revert my AAAA record to ":bef" without it breaking tor node on ":bff".Tor: 0.4.5.x-post-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40208New address disovery (IPv4 and IPv6) make it impossible to run a local lan or...2021-02-19T16:28:37Zs7rNew address disovery (IPv4 and IPv6) make it impossible to run a local lan or localhost bridge or relayThere are use cases where one wants to run a bridge or relay on their lan or localhost. This was possible until we changed address autodiscovery behavior using `AssumeReachable 1` and `PublishServerDescriptor 0` torrc options.
Now with ...There are use cases where one wants to run a bridge or relay on their lan or localhost. This was possible until we changed address autodiscovery behavior using `AssumeReachable 1` and `PublishServerDescriptor 0` torrc options.
Now with the latest alpha this is impossible.
- Scenario 1: Set `Address 127.0.0.1` and `ORPort 127.0.0.1:9001` in torrc:
Bridge / relay will start, work for some time, but complain every 60 seconds in the log file:
_Nov 23 17:04:35.000 [warn] Don't know my address while generating descriptor_
_Nov 23 17:05:35.000 [warn] Don't know my address while generating descriptor_
After 24-48 hours it eventually stop building descriptors and become unusuable.
Apparently this config `Address 127.0.0.1` doesn't trigger #40205 but I don't see why.
At debug level I only see:
_[info] address_can_be_used(): Address '127.0.0.1' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresses._
- Scenario 2: Don't set `Address` and only set `ORPort 127.0.0.1:9001` in torrc:
Bridge / relay will start, but detect the public IP address and warn:
_[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address <public_IPv4_addr>. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'._
If you have a public IPv6 address, it will also trigger #40205 that tries self reachability ignoring `AssumeReachable 1` which will make it stop working (stop building descriptors at all) after some time.
- Scenario 3: Set `Address <public_IPv4_addr>` , `ORPort 127.0.0.1:9001 NoAdvertise` and `ORPort <public_IPv4_addr> NoAdvertise` in torrc:
Bridge / relay will start, but after some time stop building descriptors entirely. It also triggers #40205 and I can't confirm or infirm if the later one makes it stop building descriptors after some time because I couldn't remove IPv6 from this box without breaking something. Depending on future testing when we fix this, I'll deploy separate vms.
Besides fixing #40205 which is the major bug here, we should allow:
- a way to disable IPv4 autodiscovery, IPv6 autodiscovery or both
- a way to run on private nets or local IP addresses v4 and link local or internal use v6 addresses maybe by setting an option like `LocalServer` that tells Tor it's OK to have localhost / lan IP on `ORPort` / `Address` and maybe automatically turn on `PublishServerDescriptor 0` and `AssumeReachable 1` if this is set.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/402790.4.5 relay with autodetected unreachable ipv6 port says it's publishing but ...2021-02-12T17:57:54ZRoger Dingledine0.4.5 relay with autodetected unreachable ipv6 port says it's publishing but then doesn'tI restarted an old relay on Tor 0.4.5, and to my surprise, it auto detects some sort of ipv6 address, even though I have an "Address" line listing an IPv4 address explicitly.
```
Feb 06 03:17:57.448 [notice] Now checking whether IPv4 OR...I restarted an old relay on Tor 0.4.5, and to my surprise, it auto detects some sort of ipv6 address, even though I have an "Address" line listing an IPv4 address explicitly.
```
Feb 06 03:17:57.448 [notice] Now checking whether IPv4 ORPort 128.31.0.39:9005 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 06 03:17:57.457 [notice] Now checking whether IPv6 ORPort [2603:400a:ffff:bb8:42a8:f0ff:fe75:6090]:9005 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 06 03:17:58.264 [notice] Self-testing indicates your ORPort 128.31.0.39:9005 is reachable from the outside. Excellent.
Feb 06 03:19:00.478 [notice] Performing bandwidth self-test...done.
```
and then it doesn't find the IPv6 address reachable (not surprising), and it sits there. I was preparing to file a "woah, are we going to lose a lot of relays?" ticket, when 19 minutes later, I get this line:
```
Feb 06 03:37:55.776 [notice] Auto-discovered IPv6 address [2603:400a:ffff:bb8:42a8:f0ff:fe75:6090]:9005 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address.
```
Well great!
But then it doesn't actually publish any descriptor.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40283relay: Don't fail if AF_INET6 family is not supported2021-02-09T16:15:51ZDavid Gouletdgoulet@torproject.orgrelay: Don't fail if AF_INET6 family is not supportedSomeone on tor-relays@ reported that when going from 044 to 045, their config failed to work:
```
ORPort 587
DIRPORT 995
```
with :
```
[notice] Opening OR listener on 0.0.0.0:587
[notice] Opened OR listener connection (ready) on 0.0....Someone on tor-relays@ reported that when going from 044 to 045, their config failed to work:
```
ORPort 587
DIRPORT 995
```
with :
```
[notice] Opening OR listener on 0.0.0.0:587
[notice] Opened OR listener connection (ready) on 0.0.0.0:587
[notice] Opening OR listener on [::]:587
[warn] Socket creation failed: Address family not supported by protocol
[notice] Opening Directory listener on 0.0.0.0:995
[notice] Closing partially-constructed OR listener connection (ready) on
0.0.0.0:587
[notice] Closing partially-constructed Directory listener connection
(ready) on 0.0.0.0:995
```
We should probably not fail this in that implicit case for IPv6 if the address is not supported.Tor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40243dirauth: IPv6 sybil detection should not use /642021-01-22T19:22:48ZDavid Gouletdgoulet@torproject.orgdirauth: IPv6 sybil detection should not use /64Offending commit is d07f17f67685d75fec8a851b3ae3d157c1e31aa3
Basically, a `/64` is a network given to end users that is the minimum routable on the Internet iirc.
If dirauth sybil protection uses that, then all relays on the same netwo...Offending commit is d07f17f67685d75fec8a851b3ae3d157c1e31aa3
Basically, a `/64` is a network given to end users that is the minimum routable on the Internet iirc.
If dirauth sybil protection uses that, then all relays on the same network won't be able to join the network. At this moment, `moria1` is rejecting 435 relays based on that behavior because at least 3 relays are in the same network and thus all get considered as sybil.
The correct thing to do here I believe is that we should use `/128` as in match the address only, not the network. Path selection is using `/32` here so it is OK to allow multiple relays from the same network as we do in IPv4, just not in the same path.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40206Include the IPv6 address in the descriptor that is going to be tested for sel...2021-01-13T14:53:55Zs7rInclude the IPv6 address in the descriptor that is going to be tested for self reachabilityFor IPv4 we log the address for which we test self reachability. Very useful for debugging.
Since we have IPv6 autodiscovery now, and we try hard to better support IPv6 (yey) we should include in this log line also the IPv6 address that...For IPv4 we log the address for which we test self reachability. Very useful for debugging.
Since we have IPv6 autodiscovery now, and we try hard to better support IPv6 (yey) we should include in this log line also the IPv6 address that is going to be tested for self reachability (if one exists of course and the relay/bridge is not IPv4 only).
Relays / bridges are not marked as running by directory authorities if they advertise an IPv6 address but are not reachable on it, so it makes full sense for the operators to know which address is being tested.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40226Loading statistics from a file for extra-info descriptors does not correctly ...2020-12-21T18:26:10ZKarsten LoesingLoading statistics from a file for extra-info descriptors does not correctly determine the last statistics blockThere's an issue with the recently added IPv6 connection statistics (apparently) not being included in extra-info descriptors, and I believe the reason is a bug in the `load_stats_file` function in `src/feature/relay/router.c`.
For exam...There's an issue with the recently added IPv6 connection statistics (apparently) not being included in extra-info descriptors, and I believe the reason is a bug in the `load_stats_file` function in `src/feature/relay/router.c`.
For example, a `stats/conn-stats` file might look like this:
```
conn-bi-direct 2020-12-13 15:48:53 (86400 s) 12,34,56,78
ipv6-conn-bi-direct 2020-12-14 15:48:53 (86400 s) 21,43,65,87
conn-bi-direct 2020-12-13 15:48:53 (86400 s) 23,45,67,89
ipv6-conn-bi-direct 2020-12-14 15:48:53 (86400 s) 32,54,76,98
```
The extra-info descriptor published by this relay would contain the following line:
```
conn-bi-direct 2020-12-14 15:48:53 (86400 s) 32,54,76,98
```
Note how these are the IPv6 numbers from the last line, not IPv4 numbers.
The bug is that `load_stats_file` finds the last occurrence of `conn-bi-direct`, which is five characters into the last line, and includes the remainder of that line in its extra-info descriptor.
What it should do is find either the last occurence of `\nconn-bi-direct` and include the file from there on (without the newline). Or if there's no such string in the file, check if the file begins with `conn-bi-direct`, and include the whole file.
@dgouletTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40205Our IPv6 Autodiscovery breaks AssumeReachable 1 torrc option2020-12-08T19:52:44Zs7rOur IPv6 Autodiscovery breaks AssumeReachable 1 torrc optionWhen last changed our IP autodiscovery code and added IPv6 support, we broke `AssumeReachable 1`
`AssumeReachable 1` tells Tor to skip self reachability tests. However, in the latest alpha, a Tor running with this torrc option, if it al...When last changed our IP autodiscovery code and added IPv6 support, we broke `AssumeReachable 1`
`AssumeReachable 1` tells Tor to skip self reachability tests. However, in the latest alpha, a Tor running with this torrc option, if it also has a working IPv6 address that is not configured in any way in torrc (as `Address` or `ORPort`) will guess the IPv6 address soon after start:
_Guessed our IP address as [public_IPv6_addr] (source: METHOD=INTERFACE)._
and immediately trigger self reachability tests including on the IPv4 address:
_Now checking whether IPv4 ORPort <public_IPv4_addr>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)_
This has a negative effect, especially on relays or bridges running on localhost / private lan with `AssumeReachable 1` and `PublishServerDescriptor 0` torrc options.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40067relay: IPv4Only ORPort without any IPv6 address configured spam logs2020-11-18T16:45:06ZDavid Gouletdgoulet@torproject.orgrelay: IPv4Only ORPort without any IPv6 address configured spam logsIf you set `ORPort 9001 IPv4Only` and have no ORPort IPv6 address configured, tor now attempts to find the address and if you happen to have a public one set on your interface, this is spammed in the notice log:
```
Jul 24 13:48:34.176 ...If you set `ORPort 9001 IPv4Only` and have no ORPort IPv6 address configured, tor now attempts to find the address and if you happen to have a public one set on your interface, this is spammed in the notice log:
```
Jul 24 13:48:34.176 [notice] Guessed our IP address as [<IPV6>] (source: METHOD=INTERFACE).
```
This is due to `check_descriptor_ipaddress_changed()`. This is because `find_my_address()` finds the address from the interface but none are set in our descriptor (`&my_ri->ipv6_addr`) resulting in this non stop log.
Not sure why this is because `ri->ipv6_addr` should be set to the same that `find_my_address()` finds from the interface...
Need to investigate this one.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/19610IPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacks2020-11-04T14:18:56ZteorIPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacksWhen an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback di...When an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback directories, fetching ~7500/500 = 15 sets of descriptors from 15 of the 25 IPv6 fallbacks.
We should improve this behaviour somehow, to avoid overloading the fallbacks. One simple way of doing this is selecting 200 fallbacks for 0.2.9 in legacy/trac#18828.
It's worth noting that this extra load only happens on bootstrap, when there are no cached microdescriptors. If an IPv6-only client has any IPv6 microdescriptors that match the current consensus, it will use those relays instead.Tor: 0.3.3.x-finalteorteorhttps://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/40068relay: Reachability test is logged every second2020-10-22T15:12:33ZDavid Gouletdgoulet@torproject.orgrelay: Reachability test is logged every secondA relay that auto discovers an IPv6 that is not reachable will attempt to launch a reachability test every second which creates a circuit each time.
From the info logs, it appears we might have a feedback loop between IPv4 bandwidth tes...A relay that auto discovers an IPv6 that is not reachable will attempt to launch a reachability test every second which creates a circuit each time.
From the info logs, it appears we might have a feedback loop between IPv4 bandwidth test and IPv6 reachability test (that should in the end never succeed).
There is this pattern every second:
```
Jul 24 14:11:53.316 [info] router_do_orport_reachability_checks(): Testing bandwidth of my IPv4 ORPort: 66.70.207.168:10001.
Jul 24 14:11:53.316 [info] origin_circuit_new(): Circuit 597 chose an idle timeout of 2445 based on 2330 seconds of predictive building remaining.
Jul 24 14:11:53.321 [info] onion_pick_cpath_exit(): Using requested exit node '$27F3833453C4006DF1E21C6BF62E4FCD8E99DEF2~WhatsGoingOn at 66.70.207.168'
Jul 24 14:11:53.328 [info] extend_info_from_node(): Including Ed25519 ID for $64A0B5722613DDFC2EB84897C550FBF4A096DE0D~NeyamRelay at 51.15.122.103
Jul 24 14:11:53.335 [info] extend_info_from_node(): Including Ed25519 ID for $77A56CB237740E24AEA2D61C8C8936232AFC1BD8~TheEpTicZeus at 54.36.227.247 and [2001:41d0:800:3a7::]
Jul 24 14:11:53.335 [info] circuit_send_first_onion_skin(): First hop: finished sending CREATE cell to '$64A0B5722613DDFC2EB84897C550FBF4A096DE0D~NeyamRelay at 51.15.122.103'
Jul 24 14:11:53.335 [info] router_do_orport_reachability_checks(): Testing reachability of my IPv6 ORPort: [<IPv6>]:10001.
Jul 24 14:11:53.335 [notice] Now checking whether IPv6 ORPort [<IPv6>]:10001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
```
Might be that `circuit_testing_opened()` keeps on asking for an IPv6 reachability test everytime the IPv4 bandwidth circuit test opens?
Or else there is a feedback loop somehow with `circuit_build_no_more_hops()` that calls `router_do_reachability_checks()` if not all `ORPort` are reachable?
Attaching a snippet of info.log showing that problem.
[info.log](/uploads/570568cf123e728fd2fd053e49d95f03/info.log)Nick MathewsonNick Mathewson