Re: [tor-relays] Exit relay not in consensus

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 c onsensus.

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 rel ay

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 finis hed 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:

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?#7BDDE0E7607A5F49578768F44CD721793FA2D7AE

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 Reachab leIPv6 flag are still listed in the metrics. h ttps://metrics.torproject.org/rs.html#details/7BDDE0E7607A5F49578768F44CD721793FA2D7AE

Any help would be appreciated.

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Hi,

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 2. Oct 2024, at 09:05, George Hartley via tor-relays <tor-relays@lists.torproject.org> wrote: