Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-11-03T13:55:05Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40494tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: dire...2021-11-03T13:55:05Zsamip537tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed;### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the follo...### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the following contents:
```
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
ORPort 443
ORPort [2001:DB8::1]:443
RelayBandwidthRate 5 MB
RelayBandwidthBurst 10 MB
AccountingMax 5 TB
AccountingStart month 3 15:00
DirPort [2001:DB8::1]:80
ExitPolicy reject *:*
```
5. Have it crash after 3-10 minutes from bandwidth self-test.
### What is the current bug behavior?
The whole Tor client crashes when set with DirPort with IPv6 address in brackets followed by port.
### What is the expected behavior?
It would not crash.
### Environment
- Which version of Tor are you using? 0.4.5.10
- Which operating system are you using? Debian 11, in an LXC container
- Which installation method did you use? Distribution package
### Relevant logs and/or screenshots
```
Oct 22 06:42:35 torrelay systemd[1]: Started Anonymizing overlay network for TCP.
Oct 22 06:42:35 torrelay Tor[6069]: Signaled readiness to systemd
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 5% (conn): Connecting to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Opening Socks listener on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opened Socks listener connection (ready) on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opening Control listener on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Opened Control listener connection (ready) on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Unable to find IPv4 address for ORPort 443. You might want to specify IPv6Only to it or set an explicit address or set Address.
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 10% (conn_done): Connected to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 14% (handshake): Handshaking with a relay
Oct 22 06:42:36 torrelay Tor[6069]: External address seen and suggested by a directory authority: <snip>
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Oct 22 06:42:37 torrelay Tor[6069]: Bootstrapped 100% (done): Done
Oct 22 06:43:36 torrelay Tor[6069]: Not advertising Directory Service support (Reason: AccountingMax enabled)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv4 ORPort <snip>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv6 ORPort [2001:DB8::1]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Self-testing indicates your ORPort [2001:DB8::1]:443 is reachable from the outside. Excellent.
Oct 22 06:45:37 torrelay Tor[6069]: Self-testing indicates your ORPort <snip>:443 is reachable from the outside. Excellent.
Oct 22 06:45:39 torrelay Tor[6069]: Performing bandwidth self-test...done.
Oct 22 06:48:37 torrelay Tor[6069]: tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed; aborting. (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: Tor 0.4.5.10: Assertion or_addr_port->port || dir_addr_port->port failed in directory_initiate_request at ../src/feature/dirclient/dirclient.c:1257: . Stack trace: (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(log_backtrace_impl+0x6c) [0x557a907880] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_assertion_failed_+0x124) [0x557a914364] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(directory_initiate_request+0x714) [0x557a9d5424] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(router_do_reachability_checks+0x184) [0x557a8d27b8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(connection_dir_reached_eof+0x13cc) [0x557a9d783c] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x1993e4) [0x557a9a93e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x68570) [0x557a878570] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(+0x234e4) [0x7f9e42e4e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x50c) [0x7f9e42ef84] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(do_main_loop+0xec) [0x557a8799e0] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_run_main+0x1c0) [0x557a8751b4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_main+0x54) [0x557a871734] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(main+0x20) [0x557a871220] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8) [0x7f9dd5c218] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x612a8) [0x557a8712a8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Main process exited, code=killed, status=6/ABRT
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Failed with result 'signal'.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 5.
Oct 22 06:48:37 torrelay systemd[1]: Stopped Anonymizing overlay network for TCP.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
```
### Possible fixesTor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40300Tor 0.4.5.6 is outputting lots of messages like: Unable to find IPv4 address ...2021-11-22T22:51:04ZerTor 0.4.5.6 is outputting lots of messages like: Unable to find IPv4 address for ORPort 9001Havent seen that one before upgrading to 0.4.5.6
```
$ /home/debian-tor/tor-0.4.5.6/src/app/tor -f /etc/tor/torrc
Feb 16 18:43:19.180 [notice] Tor 0.4.5.6 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0l, Zlib 1.2.8, Liblzm...Havent seen that one before upgrading to 0.4.5.6
```
$ /home/debian-tor/tor-0.4.5.6/src/app/tor -f /etc/tor/torrc
Feb 16 18:43:19.180 [notice] Tor 0.4.5.6 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0l, Zlib 1.2.8, Liblzma 5.2.2, Libzstd 1.1.2 and Glibc 2.24 as libc.
Feb 16 18:43:19.215 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 16 18:43:19.339 [notice] Read configuration file "/etc/tor/torrc".
Feb 16 18:43:19.455 [warn] Skipping obsolete configuration option "AllowSingleHopExits".
Feb 16 18:43:19.459 [warn] Skipping obsolete configuration option "AllowSingleHopCircuits".
Feb 16 18:43:19.491 [warn] You specified a public address '0.0.0.0:5353' for DNSPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 16 18:43:19.495 [warn] Configuration port ORPort 9001 superseded by ORPort [<MY IPV6 ADDRESS>]:9001
Feb 16 18:43:19.514 [notice] Based on detected system memory, MaxMemInQueues is set to 324 MB. You can override this by setting MaxMemInQueues by hand.
Feb 16 18:43:19.524 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://bugs.torproject.org/tpo/core/tor/8742.
Feb 16 18:43:19.650 [warn] You specified a public address '0.0.0.0:9050' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 16 18:43:19.655 [warn] You specified a public address '0.0.0.0:5353' for DNSPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 16 18:43:19.658 [warn] Configuration port ORPort 9001 superseded by ORPort [<MY IPV6 ADDRESS>]:9001
Feb 16 18:43:19.660 [notice] Opening Socks listener on 0.0.0.0:9050
Feb 16 18:43:19.663 [notice] Opened Socks listener connection (ready) on 0.0.0.0:9050
Feb 16 18:43:19.665 [notice] Opening DNS listener on 0.0.0.0:5353
Feb 16 18:43:19.683 [notice] Opened DNS listener connection (ready) on 0.0.0.0:5353
Feb 16 18:43:19.683 [notice] Opening Control listener on 127.0.0.1:9051
Feb 16 18:43:19.687 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
Feb 16 18:43:19.687 [notice] Opening OR listener on 0.0.0.0:9001
Feb 16 18:43:19.687 [notice] Opened OR listener connection (ready) on 0.0.0.0:9001
Feb 16 18:43:19.687 [notice] Opening OR listener on [<MY IPV6 ADDRESS>]:9001
Feb 16 18:43:19.687 [notice] Opened OR listener connection (ready) on [<MY IPV6 ADDRESS>]:9001
Feb 16 18:45:49.000 [notice] Bootstrapped 0% (starting): Starting
Feb 16 18:51:59.000 [notice] Starting with guard context "default"
Feb 16 18:52:02.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Feb 16 18:52:03.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address.
Feb 16 18:52:04.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Feb 16 18:52:06.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Feb 16 18:52:07.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Feb 16 18:52:07.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Feb 16 18:52:07.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Feb 16 18:52:07.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Feb 16 18:52:09.000 [notice] External address seen and suggested by a directory authority: <MY IPV4 ADDRESS>
Feb 16 18:52:51.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6731/6774). That's ok. We will try to fetch missing descriptors soon.
Feb 16 18:52:51.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6731/6774). That's ok. We will try to fetch missing descriptors soon.
Feb 16 18:52:54.000 [notice] External address seen and suggested by a directory authority: <MY IPV6 ADDRESS>
Feb 16 18:52:54.000 [notice] Bootstrapped 100% (done): Done
Feb 16 18:53:59.000 [notice] Now checking whether IPv4 ORPort <MY IPV4 ADDRESS>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 16 18:54:00.000 [notice] Now checking whether IPv6 ORPort [<MY IPV6 ADDRESS>]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success
Feb 16 18:56:35.000 [notice] Self-testing indicates your ORPort [<MY IPV6 ADDRESS>]:9001 is reachable from the outside. Excellent.
Feb 16 18:57:07.000 [notice] Self-testing indicates your ORPort <MY IPV4 ADDRESS>:9001 is reachable from the outside. Excellent. Publishing server descriptor.
Feb 16 18:57:11.000 [notice] Performing bandwidth self-test...done.
...
Feb 16 19:52:21.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
...
```Tor: 0.4.5.7-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/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/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/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/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/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/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/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/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 Mathewsonhttps://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/40065relay: Setting ORPort [<IPv6>]:auto segfault or uses wrong port2020-07-30T16:50:51ZDavid Gouletdgoulet@torproject.orgrelay: Setting ORPort [<IPv6>]:auto segfault or uses wrong portRelated to https://gitlab.torproject.org/tpo/core/tor/-/issues/32588
With current git master (after all the s55 work), setting this in your torrc will segfault:
```
ORPort 127.0.0.1:9001
ORPort [::1]:auto NoListen
```
The given IPv6 O...Related to https://gitlab.torproject.org/tpo/core/tor/-/issues/32588
With current git master (after all the s55 work), setting this in your torrc will segfault:
```
ORPort 127.0.0.1:9001
ORPort [::1]:auto NoListen
```
The given IPv6 ORPort ends up being crap, on my system: `ORPort [::1]:12845150`.
I've also experienced a segfault once with another configuration:
```
Program received signal SIGSEGV, Segmentation fault.
0x0000555555995463 in remove_duplicate_orports (ports=<optimized out>) at src/feature/relay/relay_config.c:205
205 if (!current->explicit_addr && next->explicit_addr &&
(gdb) bt
#0 0x0000555555995463 in remove_duplicate_orports (ports=<optimized out>) at src/feature/relay/relay_config.c:205
#1 check_and_prune_server_ports (n_low_ports_out=0x7fffffffd1c0, options=0x61d000001e80, ports=0x60200000a6d0) at src/feature/relay/relay_config.c:247
#2 port_parse_ports_relay (options=options@entry=0x61d000001e80, msg=msg@entry=0x7fffffffd840, ports_out=<optimized out>,
have_low_ports_out=have_low_ports_out@entry=0x555555dd11a0 <have_low_ports>) at src/feature/relay/relay_config.c:385
#3 0x00005555559f3312 in parse_ports (options=options@entry=0x61d000001e80, validate_only=validate_only@entry=1, msg=msg@entry=0x7fffffffd840,
n_ports_out=n_ports_out@entry=0x7fffffffd3e0, world_writable_control_socket=world_writable_control_socket@entry=0x7fffffffd3f0) at src/app/config/config.c:6394
#4 0x00005555559f9f0b in options_validate_cb (old_options_=<optimized out>, options_=0x61d000001e80, msg=<optimized out>) at src/app/config/config.c:3125
#5 0x0000555555a9bbdb in config_validate_single (fmt=0x555555cf36c0 <options_format>, old_options=old_options@entry=0x0, options=options@entry=0x61d000001e80,
msg_out=msg_out@entry=0x7fffffffd840) at src/lib/confmgt/confmgt.c:1229
#6 0x0000555555aa0ac0 in config_validate (mgr=0x607000000410, old_options=old_options@entry=0x0, options=options@entry=0x61d000001e80, msg_out=msg_out@entry=0x7fffffffd840)
at src/lib/confmgt/confmgt.c:1302
#7 0x00005555559f8046 in options_validate_and_set (old_options=0x0, new_options=0x61d000001e80, msg_out=0x7fffffffd840) at src/app/config/config.c:2882
#8 0x00005555559f8607 in options_init_from_string (cf_defaults=<optimized out>, cf=<optimized out>, command=command@entry=0, command_arg=command_arg@entry=0x0,
msg=msg@entry=0x7fffffffd840) at src/app/config/config.c:4578
#9 0x00005555559f94b0 in options_init_from_torrc (argc=argc@entry=3, argv=argv@entry=0x6030000325f0) at src/app/config/config.c:4412
#10 0x000055555573d011 in tor_init (argc=argc@entry=3, argv=0x6030000325f0) at src/app/main/main.c:612
#11 0x000055555573dd9c in tor_run_main (tor_cfg=tor_cfg@entry=0x604000000050) at src/app/main/main.c:1287
#12 0x000055555573b34c in tor_main (argc=3, argv=0x7fffffffdde8) at src/feature/api/tor_api.c:164
#13 0x0000555555734390 in main (argc=<optimized out>, argv=<optimized out>) at src/app/main/tor_main.c:32
```
Not sure what is happening but clearly the `auto` is not being handled normally and causing some ripple effects sometimes.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40060Add IPv6 ORPort config debug logging2020-07-24T16:40:17ZcAdd IPv6 ORPort config debug loggingChild of #32888
I made a pull request on GitHub: [PR 1932](https://github.com/torproject/tor/pull/1932)Child of #32888
I made a pull request on GitHub: [PR 1932](https://github.com/torproject/tor/pull/1932)https://gitlab.torproject.org/tpo/core/tor/-/issues/40058ipv6: check_descriptor_ipaddress_changed() should check for IPv6 changes2020-07-22T20:09:50ZDavid Gouletdgoulet@torproject.orgipv6: check_descriptor_ipaddress_changed() should check for IPv6 changesThat function is part of the `check_descriptor` callback run every minute.
It does _not_ look at IPv6.That function is part of the `check_descriptor` callback run every minute.
It does _not_ look at IPv6.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40054prop 312: Don't publish IPv6 address if ORPort is IPv4Only2020-07-21T13:03:50ZDavid Gouletdgoulet@torproject.orgprop 312: Don't publish IPv6 address if ORPort is IPv4OnlyNow that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_adv...Now that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_advertised_or_port_by_af()` and not publish a port value of 0. It is possible for instance if the `ORPort` is `IPv4Only`.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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.org