Before my last restart 6 hours ago you get a series of messages like these:
```
Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 81 v3 connections; initiated 0 and received 341 v4 connections; initiated 38535 and received 87986 v5 connections.
Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected.
Heartbeat: It seems like we are not in the cached consensus.
Heartbeat: Tor's uptime is 2 days 18:00 hours, with 185 circuits open. I've sent 41.52 GB and received 55.06 GB. I've received 105529 connections on IPv4 and 0 on IPv6. I've made 46384 connections with IPv4 and 0 with IPv6.
While not bootstrapping, fetched this many bytes: 53988798 (server descriptor fetch); 11748 (server descriptor upload); 3201890 (consensus network-status fetch); 548826 (microdescriptor fetch)
Circuit handshake stats since last time: 0/0 TAP, 2/2 NTor.
```
After my last restart I have:
```
Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Read configuration file "/etc/tor/torrc".
Based on detected system memory, MaxMemInQueues is set to 4440 MB. You can override this by setting MaxMemInQueues by hand.
Opening Control listener on 127.0.0.1:9051
Opened Control listener connection (ready) on 127.0.0.1:9051
Opening OR listener on 156.67.111.146:443
Opened OR listener connection (ready) on 156.67.111.146:443
[...]
Bootstrapped 5% (conn): Connecting to a relay
Opening Control listener on /run/tor/control
Opened Control listener connection (ready) on /run/tor/control
Self-testing indicates your ORPort 156.67.111.146:443 is reachable from the outside. Excellent. Publishing server descriptor.
Bootstrapped 10% (conn_done): Connected to a relay
Bootstrapped 14% (handshake): Handshaking with a relay
Bootstrapped 15% (handshake_done): Handshake with a relay done
Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Bootstrapped 100% (done): Done
Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.
Performing bandwidth self-test...done.
```
I can confirm that the IPv6 address is not reachable for an unknown reason. The IPv6 address and flag have been removed from the torrc file to correct the problem and don't appear in the log at restart, as shown above. IPv6 should be completely ignored by the DirAuth.
Denny
On 2024-10-01 08:06, George Hartley via tor-relays wrote:
Hi, looks like the DirAuth's think that your relay is unreachable, and so your descriptor isn't published, so your flags are not updated, this would explain the lack of change in flags.
Port 443 on 156.67.111.146 is open for me, can't test IPv6 as I have disabled it through my modem and kernel command line.
Can you attach your tor log file?
You can also adjust the log verbosity of certain "domains" within Tor like so:
[1]https://2019.www.torproject.org/docs/tor-manual.html.en#Log
Please let us know what you find.
Thanks,
George
On Tuesday, October 1st, 2024 at 1:40 PM, denny.obreham@a-n-o-n-y-m-e.net denny.obreham@a-n-o-n-y-m-e.net wrote:
My exit relay which has been running for months without a problem has not been in the cached consensus for days now. https://consensus-health.torproject.org/consensus-health.html?#7BDDE 0E7607A5F49578768F44CD721793FA2D7AE
After investigating, I thought the reason was that the IPv6 wasn't reachable anymore. It happened once before with another relay. Seems to be a problem with my ISP. Anyway, I just remove the ORPort IPv6 address and IPv6Exit flag from the torrc file and everything should return to normal. It has been days and it doesn't. Reloaded and restarted more than once since then.
What I don't understand is that the OR IPv6 address and the ReachableIPv6 flag are still listed in the metrics. h ttps://metrics.torproject.org/rs.html#details/7BDDE0E7607A5F49578768 F44CD721793FA2D7AE
Any help would be appreciated.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tuesday, 1 October 2024 19:32 denny.obreham@a-n-o-n-y-m-e.net wrote:
After my last restart I have:
Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Read configuration file "/etc/tor/torrc". Based on detected system memory, MaxMemInQueues is set to 4440 MB. You can override this by setting MaxMemInQueues by hand. Opening Control listener on 127.0.0.1:9051 Opened Control listener connection (ready) on 127.0.0.1:9051 Opening OR listener on 156.67.111.146:443 Opened OR listener connection (ready) on 156.67.111.146:443 [...] Bootstrapped 5% (conn): Connecting to a relay Opening Control listener on /run/tor/control Opened Control listener connection (ready) on /run/tor/control Self-testing indicates your ORPort 156.67.111.146:443 is reachable from the outside. Excellent. Publishing server descriptor. Bootstrapped 10% (conn_done): Connected to a relay Bootstrapped 14% (handshake): Handshaking with a relay Bootstrapped 15% (handshake_done): Handshake with a relay done Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Bootstrapped 95% (circuit_create): Establishing a Tor circuit Bootstrapped 100% (done): Done
That looks good :-)
Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.
It could be that your provider has throttled you temporarily.
Performing bandwidth self-test...done.
I can confirm that the IPv6 address is not reachable for an unknown reason. The IPv6 address and flag have been removed from the torrc file to correct the problem and don't appear in the log at restart, as shown above. IPv6 should be completely ignored by the DirAuth.
With some providers you get the IPv6 prefix too late¹ and systemd stops tor because of errors. Unfortunately, I have one of those too. After a reboot I have to log in and do:
systemctl list-units --failed systemctl stop tor systemctl reset-failed systemctl start tor
That's one reason why I don't have an auto reboot after upgrade but would like to receive an email from the system. <- @toralf ;-)
¹Even the sysctl settings don't help. # Disable IPv6 autoconf and router advertising net.ipv6.conf.all.autoconf=0 net.ipv6.conf.default.autoconf=0 net.ipv6.conf.all.accept_ra=0 net.ipv6.conf.default.accept_ra=0
# Do not accept DAD net.ipv6.conf.all.accept_dad=0 net.ipv6.conf.default.accept_dad=0
# Disable DAD transmits net.ipv6.conf.all.dad_transmits=0 net.ipv6.conf.default.dad_transmits=0
It could be that your provider has throttled you temporarily.
I don't think so, I get that message on a dedicated 10 GbE link with little to no use except for the exit relay on it.
Also, if his relay publishes it's descriptor, then why Metrics won't reflect that?
It should show it as online, as you don't need IPv6 to be reachable to get the online flag.
-GH
On Tuesday, October 1st, 2024 at 7:55 PM, boldsuck via tor-relays tor-relays@lists.torproject.org wrote:
On Tuesday, 1 October 2024 19:32 denny.obreham@a-n-o-n-y-m-e.net wrote:
After my last restart I have:
Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Read configuration file "/etc/tor/torrc".
Based on detected system memory, MaxMemInQueues is set to 4440 MB. You can override this by setting MaxMemInQueues by hand.
Opening Control listener on 127.0.0.1:9051
Opened Control listener connection (ready) on 127.0.0.1:9051
Opening OR listener on 156.67.111.146:443
Opened OR listener connection (ready) on 156.67.111.146:443
[...]
Bootstrapped 5% (conn): Connecting to a relay
Opening Control listener on /run/tor/control
Opened Control listener connection (ready) on /run/tor/control
Self-testing indicates your ORPort 156.67.111.146:443 is reachable from the outside. Excellent. Publishing server descriptor.
Bootstrapped 10% (conn_done): Connected to a relay
Bootstrapped 14% (handshake): Handshaking with a relay
Bootstrapped 15% (handshake_done): Handshake with a relay done
Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Bootstrapped 100% (done): Done
That looks good :-)
Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.
It could be that your provider has throttled you temporarily.
Performing bandwidth self-test...done.
I can confirm that the IPv6 address is not reachable for an unknown reason. The IPv6 address and flag have been removed from the torrc file to correct the problem and don't appear in the log at restart, as shown above. IPv6 should be completely ignored by the DirAuth.
With some providers you get the IPv6 prefix too late¹ and systemd stops tor because of errors. Unfortunately, I have one of those too. After a reboot I have to log in and do:
systemctl list-units --failed systemctl stop tor systemctl reset-failed systemctl start tor
That's one reason why I don't have an auto reboot after upgrade but would like to receive an email from the system. <- @toralf ;-)
¹Even the sysctl settings don't help. # Disable IPv6 autoconf and router advertising net.ipv6.conf.all.autoconf=0 net.ipv6.conf.default.autoconf=0 net.ipv6.conf.all.accept_ra=0 net.ipv6.conf.default.accept_ra=0
# Do not accept DAD net.ipv6.conf.all.accept_dad=0 net.ipv6.conf.default.accept_dad=0
# Disable DAD transmits net.ipv6.conf.all.dad_transmits=0 net.ipv6.conf.default.dad_transmits=0
-- ╰_╯ Ciao Marco!
Debian GNU/Linux
It's free software and it gives you freedom!_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 2. Oct 2024, at 09:05, George Hartley via tor-relays tor-relays@lists.torproject.org wrote:
It could be that your provider has throttled you temporarily.
I don't think so, I get that message on a dedicated 10 GbE link with little to no use except for the exit relay on it.
Also, if his relay publishes it's descriptor, then why Metrics won't reflect that?
It should show it as online, as you don't need IPv6 to be reachable to get the online flag.
it looks like your upstream is maliciously messing with your traffic. I am noticing a distinct difference between two traces, one directly from my diraut's IPv4, another from a different host on the same network:
dirauth: 1 informatik.gate.uni-erlangen.de (131.188.40.1) 0.522 ms 0.510 ms 0.506 ms 2 constellation.gate.uni-erlangen.de (131.188.20.37) 0.485 ms 30.734 ms 30.714 ms 3 yamato.gate.uni-erlangen.de (131.188.20.252) 0.530 ms 0.618 ms 0.740 ms 4 cr-erl2-hundredgige0-7-0-5.x-win.dfn.de (188.1.234.229) 0.831 ms 0.881 ms 0.962 ms 5 cr-fra2-be11.x-win.dfn.de (188.1.144.222) 4.694 ms 4.784 ms 4.814 ms 6 ae56.edge9.Frankfurt1.Level3.net (62.67.67.153) 23.379 ms 14.507 ms 14.478 ms 7 * * * 8 if-ae-68.tcore2.fr0-frankfurt.as6453.net (80.231.65.22) 15.707 ms 15.677 ms 15.651 ms 9 * * * 10 * * * 11 * * * 12 if-bundle-15-2.qcore1.emrs2-marseille.as6453.net (80.231.154.33) 25.474 ms * 25.201 ms 13 * * * 14 * * * 15 * * *
other host: 1 informatik.gate.uni-erlangen.de (131.188.40.1) 0.705 ms 0.676 ms 0.626 ms 2 constellation.gate.uni-erlangen.de (131.188.20.37) 0.571 ms 0.538 ms 0.508 ms 3 yamato.gate.uni-erlangen.de (131.188.20.252) 1239.238 ms 1239.152 ms 1239.124 ms 4 cr-erl2-hundredgige0-7-0-5.x-win.dfn.de (188.1.234.229) 1239.135 ms 1239.115 ms 1239.075 ms 5 cr-fra2-be11.x-win.dfn.de (188.1.144.222) 4.337 ms 4.395 ms 4.497 ms 6 ae56.edge9.Frankfurt1.Level3.net (62.67.67.153) 4.123 ms 8.507 ms 8.461 ms 7 * * * 8 * ix-bundle-68.qcore1.fr0-frankfurt.as6453.net (80.231.65.22) 14.755 ms * 9 * * * 10 * * * 11 * * * 12 if-bundle-15-2.qcore1.emrs2-marseille.as6453.net (80.231.154.33) 25.063 ms 25.363 ms * 13 14.142.189.178.static-mumbai.vsnl.net.in (14.142.189.178) 141.605 ms 138.409 ms 138.429 ms 14 142.79.255.2 (142.79.255.2) 139.856 ms 142.79.255.0 (142.79.255.0) 138.112 ms 142.79.255.2 (142.79.255.2) 134.489 ms 15 142.79.252.34 (142.79.252.34) 240.947 ms 242.328 ms 245.329 ms 16 sortie-tor.a-n-o-n-y-m-e.net (156.67.111.146) 249.023 ms 243.328 ms 247.636 ms
While this traffic interference lasts, you will not be able to reliably upload descriptors, get measured as reachable, etc. That might also explain why your descriptors do not make it to metrics, as your upstream is preventing you from ever getting them out there.
I hope you will be able to talk some sense into your upstream!
Cheers and thanks Sebastian
On Wednesday, 2 October 2024 21:24 Sebastian Hahn wrote:
On 2. Oct 2024, at 09:05, George Hartley via tor-relays tor-relays@lists.torproject.org wrote:
It could be that your provider has throttled you temporarily.
I don't think so, I get that message on a dedicated 10 GbE link with little to no use except for the exit relay on it.
Also, if his relay publishes it's descriptor, then why Metrics won't reflect that?
It should show it as online, as you don't need IPv6 to be reachable to get the online flag.
it looks like your upstream is maliciously messing with your traffic. I am noticing a distinct difference between two traces, one directly from my diraut's IPv4, another from a different host on the same network:
A few years ago, Roger emailed me that he could not reach a service @ mit.edu (ASN3) via my exit. I had 2 exits at the same provider with same torrc, network config, IPtables, etc. One had "mystery null routes between Tor relays." https://gitlab.torproject.org/tpo/core/tor/-/issues/40357
I then switched to a different exit port and the problem was solved.
tor-relays@lists.torproject.org