- tor-relays - lists.torproject.org

Tor Relay on Gandi.net
by protectmyonion 14 Nov '22

14 Nov '22

mailto:tor-relays@lists.torproject.org I was wondering if anyone had experience running a Tor relay on Gandi. According to [good-bad-isps](https://community.torproject.org/relay/community-resources/g…, Gandi supports all relays. However, I contacted support asking them their policy on Tor and if their policy was the same for all Tor relays. Their response was basically 'You can install any software you want, but its use is subject to French law and our terms of service. If a complaint is received, the Abuse department will take appropriate action and notify you.'. This was pretty vague and kind of seemed like they didn't know what Tor was. I responded and tried to explain what Tor was using most of what was in the Common Boilerplate template. I explained that there were things that I could do to reduce potential abuse, like limiting the exit policy, but that there was always still potential for abuse. The next response came from the Abuse department and basically said 'Any illegal activity on your IP will result in your server being shutdown.'. Based on this, it seems like Gandi is not a good ISP for Tor exits, but likely fine for all other relays. What's a little confusing is that according to Tor metrics, Gandi currently has Tor exits. It is only 2, but nevertheless, they exist. [France](https://metrics.torproject.org/rs.html#search/as:AS203476) location has 2 exits, but [Luxembourg](https://metrics.torproject.org/rs.html#search/as:AS29169) has none. I'm not sure if [good-bad-isps](https://community.torproject.org/relay/community-resources/g… should be updated, given there's conflicting information, but I figured I'd ask if anyone had personal experience with Gandi. Thanks.

3 2

new bridge
by Anonforpeace 10 Nov '22

10 Nov '22

Hello: I have setup a new bridge. Relay Search confirms it is up, however I wanted to verify with you as well. The nickname is: h4ck3rspace Thank you Sent with [Proton Mail](https://proton.me/) secure email.

1 0

Tor DDoS Mitigation iptables scripts updated to version 3.0.0
by Chris 09 Nov '22

09 Nov '22

1 0

Middle relay and snowflake
by andrew reid 09 Nov '22

09 Nov '22

Is it possible to run a tor relay and a snowflake on the same IP. I have had the snowflake add on installed on my browser for a few months and noticed it has never gotten any traffic. Is this because of the tor relay on the same IP ?

1 0

State of the Onion 2022
by Gaba 08 Nov '22

08 Nov '22

Hi! We're happy to announce that the State of the Onion, a livestream event highlighting updates from onion-world over the last year, is returning this month! This year, we'll State of the Onion will be a two-part event: - Wednesday, Nov 9, State of the Onion: the Tor Project @ 17:00-18:30 UTC: https://www.youtube.com/watch?v=uSyBZ7GIzJY - Wednesday, Nov 16, State of the Onion: the Tor community @ 17:00-18:30 UTC: https://www.youtube.com/watch?v=O-7k0PjnBbk Everyone is invited to hear news, accomplishments, challenges, and next steps of all the Tor Project's teams + Tor community projects during these live events. More information about the Tor Project's event in https://blog.torproject.org/state-of-the-onion-2022/ cheers, gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

preventing DDoS is more than just network filtering
by Toralf Förster 07 Nov '22

07 Nov '22

The graphs in [1] and [2] are IMO good examples related to [3]: "... in addition to network filtering, the (currently) sharp input signal ... is transformed into a smeared output response ... This shall make it harder for an attacker to gather infromation using time correlation techniques." Feedback is welcome. [1] https://github.com/toralf/torutils/blob/main/doc/network-metric.svg [2] https://github.com/toralf/torutils/blob/main/doc/network-metric-nextday.svg [3] https://github.com/toralf/torutils/tree/main#block-ddos-traffic -- Toralf

1 0

Need a little assistance with a relay
by Ronvau 05 Nov '22

05 Nov '22

Hello Tor, I am looking to set up a relay but have not been successful yet. ALthough I believe I followed instructions, the relay "Walton" does not appear to be functioning as I would expect. I was using SNAP as a vehicle to launch the relay but no luck there as it fails as well. Is there anyone that can work with me to get this relay up and online?? Thank you.Ron V.

3 3

Re: [tor-relays] security update for obfs4proxy
by Toralf Förster 03 Nov '22

03 Nov '22

On 10/14/22 19:09, meskio wrote: > The upstream changelog is here: > https://gitlab.com/yawning/obfs4/-/blob/master/ChangeLog > But I understand is not easy to understand what the problem is from that > changelog. Indeed. BTW the fix was made 5 weeks ago, so I do assume, the (eg. Debian) package needed time to stabilize, or ? -- Toralf

3 3

My bridge has no distribution mechanism
by Keifer Bly 30 Oct '22

30 Oct '22

https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… Hey, So my bridge, listed above, says it has no distribution mechanism. Does this mean it is not currently being used? Thank you. --Keifer

1 0

DoS attacks -- status update
by Georg Koppen 28 Oct '22

28 Oct '22

Hello everyone! It's been a while since we last provided some update on this mailing list about our ongoing work fighting several DoS attacks. We can use the attached graph about detected overload over the last couple of months to show what is going on and what we do/plan to do about it. The first noteworthy incident on that graph is the sharp rise in overloaded non-exit nodes since the middle of July caused by a drop of onionskins[1] which the relay's available CPU/memory can't handle anymore. There are currently two ideas we are working on to cope with such a flood of onionskins: 1. Developing a Proof of Work (PoW) system to has a rate-limitation knob rejecting the load of onionskins while letting legitimate ones through.[2] We still need to solve some design issues (feel free to help!) but hope to have that feature integrated into Tor soon. 2. Relay operators started to experiment with iptables/nftables rules and having the right ones available might be a good stopgap approach against the onionskin related DoS. We are coordinating that effort[3], so we have something available to propose to the wider community, which is kept up-to-date and limits the risks of traffic overblocking. Feel free to help as well with that effort. The other noteworthy incident started around September 13 when exit nodes began to get overloaded (while the other DoS was and is still ongoing). Unfortunately, that exit related DoS is heavily impacting our users' experience as can be seen in our OnionPerf data[4]. While we are still investigating the nature of that DoS attack it turns out that blocking particular IP addresses with ExitPolicy rules seems to help on exit nodes this is tested on. The Artikel10 exit node operators provided even a script recently[5] to help with that (much appreciated, thanks!). This approach is highly experimental at this point and it might help us at least to come up with an actual design idea to counter that particular exit DoS. Thanks, Georg [1] For information about overload in general and what "drop of onionskins" means, see: https://support.torproject.org/relay-operators/#relay-bridge-overloaded. It contains as well a guide on how to enable MetricsPort monitoring yourself so you see the actual metrics of your own relay. [2] https://gitlab.torproject.org/tpo/core/tor/-/issues/40634 [3] https://gitlab.torproject.org/tpo/community/support/-/issues/40093 [4] https://metrics.torproject.org/torperf.html [5] https://lists.torproject.org/pipermail/tor-relays/2022-October/020848.html

1 0

MetricsPort: tor_relay_connections_total type confusion
by nat＠danwin1210.de 28 Oct '22

28 Oct '22

Hello David, again, thanks for your work on adding more metrics to tor's MetricsPort! Many relay operators will love this and documentation will be useful [1]. I reported https://gitlab.torproject.org/tpo/core/tor/-/issues/40699 which got closed yesterday, but there was likely a misunderstanding and the changes did not solve the underlying issue. The core issue is: The metric called tor_relay_connections(_total) [2][3] contains a mix of different types (gauge, counter). When mixing types in a single metric, the TYPE definition will always be wrong for one or the other value. For example grafana will show this if you use a counter metric without rate(): "Selected metric is a counter. Consider calculating rate of counter by adding rate()." It is a best practice to avoid mixing different types in a single metric. >From the prometheus best practices [4]: "As a rule of thumb, either the sum() or the avg() over all dimensions of a given metric should be meaningful (though not necessarily useful). If it is not meaningful, split the data up into multiple metrics. For example, having the capacity of various queues in one metric is good, while mixing the capacity of a queue with the current number of elements in the queue is not." An idea to address the underlying issue: One connection metric for counter and one for gauge: - tor_relay_connections_total for counters, like the current label state="created" - tor_relay_connections for gauge metrics, like the current label state="opened". "rejected" also appears to be a gauge metric. Another nice feature of these metrics would be to have a label for what type of system is connecting (src="relay", src="non-relay") - more on that in yesterday's email. A tool by toralf [4] also shows these and uses the source IP but tor itself does not need to look at the source IP to determine the type, something discussed in last week's relay operator meetup. best regards, nat [1] https://gitlab.torproject.org/tpo/web/support/-/issues/312 [2] https://gitlab.torproject.org/tpo/core/tor/-/commit/06a26f18727d3831339c138… [3] https://gitlab.torproject.org/tpo/core/tor/-/commit/6d40e980fb149549bbef5d9… [4] https://prometheus.io/docs/practices/naming/

2 2

Upcoming OpenSSL 3 security bugfix release
by Georg Koppen 28 Oct '22

28 Oct '22

Hello relay operators! If you are running OpenSSL 3 please be aware that you might need to upgrade it to 3.0.7 as fast as possible on next Tuesday (Nov 1). In an announcement[1] it got said 3.0.7 fixes a CRITICAL security issue. Operators running on the 1.1 series are fine as far as we know so far. Georg [1] https://www.openwall.com/lists/oss-security/2022/10/25/4

1 0

(Invitation) Join us! Tor Relay Operator Meetup - October 22, 2022 - 1900 UTC
by gus 25 Oct '22

25 Oct '22

Dear relay operators, The next Tor relay operator meetup will happen on Saturday, October 22 at 19.00 UTC. ## Where BigBlueButton: https://tor.meet.coop/gus-og0-x74-dzn ## Agenda (WIP) * Announcements * Tor and Snowflake in Iran * EOL rejection * State of DoS attack * New network health project * Q&A * Next Tor Relay Operator Meetup Meeting pad: https://pad.riseup.net/p/tor-relay-op-meetup-o22-keep Everyone is free to bring up additional questions or topics at the meeting itself. ## Registration No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

4 5

Performance issues/DoS from outgoing Exit connections
by Alexander Dietrich 22 Oct '22

22 Oct '22

Hello, on the evening of 2022-10-18, we (Artikel10) started getting alerts about our Tor servers, while our traffic declined sharply. When we investigated, we found that there were hundreds of thousands of TCP connections (per server) open to a single address, orders of magnitude more than any other address. We blocked this address via "ExitPolicy reject", then another one, and since then things seem to have improved. I have thrown together a small Python script to detect this and generate "ExitPolicy reject" lines automatically: https://github.com/artikel10/surgeprotector This is still experimental, so if you decide to give the script a try, please keep an eye on it. Kind regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

3 3

List number of circuits per connection
by Logforme 20 Oct '22

20 Oct '22

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 Like most relays mine has been targeted by the DoS attack. Hundreds of VPS IPs creating millions of IP connections. This I mitigated with rules in my firewall. Looking at the firewall counters it looks like that attack has now stopped. However the relay is still overloaded from lots of circuit creations. Normally my little relay reports around 100K circuits open in the log file but since the overloading started it's closer to 1M circuits open. All these circuit creations put a strain on the CPU, sometime pegging it at 100% (4 core i5-4670K CPU @ 3.40GHz). Worse, it seems to eat memory. Normally the tor process uses about 3GB (out of 8GB) but I have seen it quickly shoot up to using all memory and all swap. I assume this is because of the circuit creation DoS (it's new behavior) and what causes the oom killer to kill the tor process at least once a day or so. So, how do I mitigate the circuit creation DoS? My immediate thought is to identify if there are a few IPs responsible for the majority and add those to my firewall naughty list. Is there a way to query the tor process about number of open circuits mapped to IP addresses?

3 4

bridge down
by Anonforpeace 19 Oct '22

19 Oct '22

Hello: My Tor Bridge has been down for awhile as I was moving to a new home. I have been trying to bring it up again and have been receiving the messages you see below. I have checked the the tor project status and see that there is a Ddos attack affecting the network. Is that why I am getting this or am I doing something wrong? Thank you. darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ sudo systemctl enable --now tor.service Synchronizing state of tor.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable tor darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ sudo systemctl restart tor.service darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ journalctl -e -u tor@default Oct 16 00:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 00:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 01:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 01:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 > Oct 16 01:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 01:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 02:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 02:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 > Oct 16 02:14:16 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: No circuits are opened. Relaxed timeout for circuit 875 (a Testing circuit 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the> Oct 16 02:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 02:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 03:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 03:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 > Oct 16 03:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 03:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 04:00:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Heartbeat: Tor's uptime is 1 day 12:00 hours, with 0 circuits open. I've sent 6.47 MB and received 36.85 MB. I've received 0 connections on IPv4 and 0 on IPv6. I've made 161 c> Oct 16 04:00:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: While not bootstrapping, fetched this many bytes: 28998071 (server descriptor fetch); 2431916 (consensus network-status fetch); 310310 (microdescriptor fetch) Oct 16 04:00:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Heartbeat: Since last heartbeat message, I have seen 0 unique clients. Oct 16 04:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 04:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 > Oct 16 04:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 04:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 05:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 05:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 > Oct 16 05:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 05:24:16 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: No circuits are opened. Relaxed timeout for circuit 920 (a Testing circuit 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the> Oct 16 05:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 06:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 06:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 > Oct 16 06:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 06:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 07:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 07:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 > Oct 16 07:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 07:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 08:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 08:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 > Oct 16 08:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 08:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 09:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 09:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 > Oct 16 09:02:21 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 103 buildtimes. Oct 16 09:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 09:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 10:00:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Heartbeat: Tor's uptime is 1 day 18:00 hours, with 0 circuits open. I've sent 7.75 MB and received 43.92 MB. I've received 0 connections on IPv4 and 0 on IPv6. I've made 188 c> Oct 16 10:00:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: While not bootstrapping, fetched this many bytes: 34600394 (server descriptor fetch); 2858305 (consensus network-status fetch); 361968 (microdescriptor fetch) Oct 16 10:00:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Heartbeat: Since last heartbeat message, I have seen 0 unique clients. Oct 16 10:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 10:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 > Oct 16 10:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 10:40:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 11:00:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Plea> Oct 16 11:00:15 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 > Oct 16 11:05:13 darkhoodie-HP-Compaq-Pro-6300-SFF systemd[1]: Stopping Anonymizing overlay network for TCP... Oct 16 11:05:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Oct 16 11:05:13 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Delaying directory fetches: We are hibernating or shutting down. Sent with [Proton Mail](https://proton.me/) secure email.

4 4

Most useful bridge distribution
by Thoughts 12 Oct '22

12 Oct '22

Hi all - Running a bridge, and per some stats I saw earlier Moat seems to be the most popular distribution method. Just curious is something else is recommended? Some seem less secure than others, but I don't know the methods used to prevent abuse. Would appreciate guidance. Cheers, Kevin

2 1

Tor 0.4.6.x is unsupported, please upgrade
by Georg Koppen 09 Oct '22

09 Oct '22

Hello! To repeat what recently[1] got brought up: it's time to get relays upgraded in case they are running the EOL 0.4.6.x Tor series. We'll start reaching out to operators with valid contact information this week and plan to reject relays which are still on 0.4.6.x in about 5 weeks from now on at the end of September. You can follow along that process in our bug tracker[2] if you want. For the general processes around dealing with EOL relays in the Tor network see my mail from last October[3]. Feedback and improvements are welcome, as always. Georg [1] https://twitter.com/torproject/status/1557392816250441728 [2] https://gitlab.torproject.org/tpo/network-health/team/-/issues/252 [3] https://lists.torproject.org/pipermail/tor-relays/2021-October/019862.html

4 4

many connections
by Sandro Auerbach 09 Oct '22

09 Oct '22

Hello, After changing my server, the connections settled between 6000-8000 incoming connections in the first 2 weeks of the warm-up period. (Guard/non exit) Since it seems that many relays have been overloaded in the last few weeks, I think a big DDOS is running again. Yesterday I tried to reduce the bandwidth a bit.I've just looked again and see over 26800 incoming connections. Is this even possible or is it more of a bug in the system?30 minutes later still 22000 connections... Have you observed something similar? Many greetings Sandro

4 9

'nudging' is a crime - 1B98468097E7F3FF102926423DF44315E414CBCF: down
by Fred 08 Oct '22

08 Oct '22

1 0

Lots of dropped onion skins
by Jonathan D. Proulx 07 Oct '22

07 Oct '22

HI All, I was checkign up on my (middle) relay stats: https://metrics.torproject.org/rs.html#details/9715C81BA8C5B0C698882035F75C… and saw an "overload" banner, after some learning I see lots of onionskins being dropped in the metrics: tor_relay_load_onionskins_total{type="tap",action="processed"} 890 tor_relay_load_onionskins_total{type="tap",action="dropped"} 0 tor_relay_load_onionskins_total{type="fast",action="processed"} 0 tor_relay_load_onionskins_total{type="fast",action="dropped"} 0 tor_relay_load_onionskins_total{type="ntor",action="processed"} 3096501 tor_relay_load_onionskins_total{type="ntor",action="dropped"} 2827649 tor_relay_load_onionskins_total{type="ntor_v3",action="processed"} 3096501 tor_relay_load_onionskins_total{type="ntor_v3",action="dropped"} 2827649 processed and dropped are growing pretty rapidly so maybe this is a know and ongoing attack, but I don't see why I would be dropping. The system has 8 corse and 8G RAM neither of which seems stressed. Less than 2G or RAM is in use and systrrem load (top under linux) reports ~70% idle (I guess if they're coming in really tight bursts it could average to that and still be droppong peaks). Anyone know what this is or have hints as to where to look? Thanks, -Jon

2 1

Re: [tor-relays] consensus weight tanking
by Me 07 Oct '22

07 Oct '22

Thanks for the prompt response. My apologies for the omission in the original post. My relays are called 405test1 and 405test2. Both relays are vm's on a proxmox server with the only difference in set up being port numbers. I have had both operating since July 2022 with no issues. Thanks again! On October 6, 2022 4:59:22 AM CDT, tor-relays-request(a)lists.torproject.org wrote: >Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-relays digest..." > > >Today's Topics: > > 1. Re: Moving middle relays to bridges? (Chris) > 2. Consensus weight tanking (Me) > 3. Re: Consensus weight tanking (Georg Koppen) > 4. Re: many connections (Chris) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 05 Oct 2022 05:32:20 -0400 >From: Chris <tor(a)wcbsecurity.com> >To: tor-relays(a)lists.torproject.org >Subject: Re: [tor-relays] Moving middle relays to bridges? >Message-ID: <2d1975a2-6362-48d3-8dc3-05bd16797797(a)wcbsecurity.com> >Content-Type: text/plain; charset="utf-8" > >Bridges more or less function as guard relays except their IP addresses are not known. Having a bridge with an IP address that's already know somehow defeats the purpose. > >As far as I'm concerned the list of relays should not be public. Only exit relays need to be known for liability reasons. Once we stop publishing IP addresses of relays, the need for bridges will be greatly reduced. > >That being said, I believe if your relay is no longer a relay for a week, it will be removed from the public relay list. Not sure if it will be removed from the censors' list. >?? > > >-------- Original Message -------- >From: "Isaac Grover, Aileron I.T." <igrover(a)aileronit.com> >Sent: Tue Oct 04 12:15:52 EDT 2022 >To: "tor-relays(a)lists.torproject.org" <tor-relays(a)lists.torproject.org> >Subject: [tor-relays] Moving middle relays to bridges? > >Good morning, > >According to tor metrics, there have been nearly three times the number of relays as bridges over the last three months so I would like to move my handful of middle relays to bridges. They will keep their same IP address. Is there a best practice with regards to doing this so the directories don't get confused? > >Make your day great, >Isaac Grover > > > >------------------------------------------------------------------------ > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 1

Your computer is too slow to handle this many circuit creation requests
by teamcat＠genocide.fun 07 Oct '22

07 Oct '22

Hello, After setting up a relay, I noticed that my log file was full of "Your computer is too slow to handle this many circuit creation requests" messages. This seems odd to me, as htop reports that my CPU and memory usage is nowhere near full. I'm running on two cores and 8 GB of RAM, and it's averaging about 40% usage on both cores and 2 GB of RAM usage. I've used the tor-ddos iptables rules that were suggested in a previous message thread, but it doesn't seem to have done anything to address the problem. (https://github.com/Enkidu-6/tor-ddos) I've also configured /etc/sysctl.conf to support a traffic flow as outlined in the github repo. Here is the link to the metrics page for my relay. https://metrics.torproject.org/rs.html#details/74181AB4D1A7D403ED9F190FAC92… Is this something that I should be concerned about, and work to mitigate? I am able to migrate my relay to much more powerful hardware, but obviously that would incur additional cost, so if there is some way to fully utilize my existing hardware I would prefer that. Regards, Evan

1 0

(FYI) Rejecting outdated snowflake proxies
by gus 06 Oct '22

06 Oct '22

Hello everyone, As part of scaling snowflake bridge and adding distributed snowflake server support[1], this week the Anti-censorship Team started to reject *outdated* snowflake proxies that can't support this feature (distributed server support). This will result in a loss of 30% of unrestricted NAT proxies. Read below the instructions how to check your snowflake proxy version: - WebExtension: 0.6.2. - Docker: To check the version: $ docker run thetorproject/snowflake-proxy -v should include "-allowed-relay-hostname-pattern" in the output. To update: $ docker pull thetorproject/snowflake-proxy - Standalone with Go Toolchain: To check the version: $ proxy -v should include "-allowed-relay-hostname-pattern" in the output. To update: $ go install git.torproject.org/pluggable-transports/snowflake.git/v2/proxy@latest If you need help, please check this Forum post: https://forum.torproject.net/t/please-update-your-snowflake-proxy-to-help-u… Thank you! gus [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… -- The Tor Project Community Team Lead

2 1

Consensus weight tanking
by Me 06 Oct '22

06 Oct '22

Good day, Not sure if this would be the proper avenue to pursue this. I operate a couple of middle relays from my home server. All seemed well until this morning. Three days ago one was promoted to guard status while the other lags behind. This morning I check the Tor metrics page and the consensus weight graphs on both relays have bottomed out. The other metrics do not have appeared to have remained normal for daily operations. Any suggestions or input are greatly appreciated

2 1

Moving middle relays to bridges?
by Isaac Grover, Aileron I.T. 05 Oct '22

05 Oct '22

Good morning, According to tor metrics, there have been nearly three times the number of relays as bridges over the last three months so I would like to move my handful of middle relays to bridges. They will keep their same IP address. Is there a best practice with regards to doing this so the directories don't get confused? Make your day great, Isaac Grover

3 2

Thoughts about potentially abusive config option for exit nodes
by abuse-node49＠posteo.de 03 Oct '22

03 Oct '22

I did not manage to find anywhere on the new website the current config options of the torrc. So I ask the question here, although it may be already outdated. This is the third time I have had contact with the police about Exits Relays. That's why it occurred to me that someone might be acting targeted, because I run more than one node. Looking for configurations that allow dedicated IP addresses, I found the torrc-config option 'StrictNodes 1' in conjunction with 'ExitNodes [IP/Nickname/Key]' on the web. There were also hints that something had been changed before, but I tried it on a local installation. The goal was to use a specific exit address. StrictNodes 1 ExitNodes [MY_EXIT_NODE_IP] First I had a typo and the Tor service did not start. After the correction it worked and I got into the network. The conclusion remained that Tor accepts these configuration lines. The problem with this is, should this config line really allow a dedicated exit as the sole exit point into the network, the operator of that exit could be targeted and harmed with illegal traffic. In Metrics it is easy to show whole Tor families that always belong to a single operator. It would be nice if the developers remove the possibility to specify a dedicated IP address/nickname/key, if not already done. The config option 'Exitnodes {COUNTRY_CODE}' should remain though. Kind regards, Olaf

1 0

bridge distribution
by potlatch 28 Sep '22

28 Sep '22

[0] FB45183DD82D572CA2B2641C1AB0EB0D8CE7B858 Sent with [Proton Mail](https://proton.me/) secure email.

3 2

bridge distribution
by potlatch 24 Sep '22

24 Sep '22

People, I have a bridge [0] with a bridge distribution mechanism of "non". It's been that way since May 2022. What gives? Should I remove it from the network as unless> potlatch Sent with [Proton Mail](https://proton.me/) secure email.

1 0

Best practices for the hosting provider of Tor exit nodes?
by Isaac Grover, Aileron I.T. 15 Sep '22

15 Sep '22

Good afternoon, As I'm reaching out to hosting providers worldwide to see if hosting Tor exit nodes is within their ToS and AUP, most hosting providers are requesting hardware specifications and bandwidth requirements; however, I would like to point them to a resource showing best practices for the hosting provider, and maybe one that shows expectations of the Tor exit node operator as well - for example SWIP'ing the IP address(es) to the exit node operator - so that the hosting provider knows what the exit node operator expects of them, and what they should expect of the exit node operator. Does such a resource exist, and if not, what would you request/add in such a resource? Make your day great, Isaac Grover

1 0

knock knock, police is here
by volker.mink＠gmx.de 13 Sep '22

13 Sep '22

Hi folks. On Tuesday morning police knocked on my door, performing a full house search. Some Nazis used TOR to send nazi-emails to several schools in Germany. Unfortunately their mails left one of my Exit Servers from dark- to clearweb, so an ip address, registered on my name, was the last stamp. Now im accused of Volksverhetzung (german, try to find a good translation). It means spreading bad nazi bullshit to the internet. I can take this down by showing them German Telemediengesetz §8, which protects TOR operators in Germany. Unfortunately they found some dope (yea, 420guy here) during the house search, which makes thing even more complicated. Now I am considering shutting down all my exits. I promise you guys, there is nothing more bad than a police house search in the early morning hourse. Even a burglary would be less worse. Burglars come, steal, go and you never hear again from them. Police comes, searches through all your belongings, destroys your privacy, is allowed to take ALL what they want - and they will send you bad bad letters afterwards. What are your thoughts about this? Best regards, volker

5 6

a characteristic of recent attacks?
by Scott Bennett 01 Sep '22

01 Sep '22

The vast majority of recent surges of unusual activity on my humble relay, which I take as likely being attacks, result in large changes in the hour-to-hour statistic shown below in these lines extracted from the hourly heartbeat message groups. Aug 31 19:02:28.549 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1706742 INTRODUCE2 rejected. Aug 31 20:02:28.546 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1706742 INTRODUCE2 rejected. Aug 31 21:02:28.549 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1706742 INTRODUCE2 rejected. Aug 31 22:02:28.544 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1770970 INTRODUCE2 rejected. Aug 31 23:02:28.556 [notice] Heartbeat: DoS mitigation since startup: 16 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 2013266 INTRODUCE2 rejected. The most recent such surge appears to have ended less than an hour ago. Note that there was no change in the count of "INTRODUCE2 rejected" for many hours leading up to the onset of unusual activity, though I've only shown three prior hours' worth. Then there is an increase of 63227 in this count during the first hour and another 41296 during the second hour. Often during these periods the input appears to be maxed out, and sometimes the output rate is still higher by several hundred KB/s. My question is, do other relay operators whose relays are being attacked see the same phenomenon? In addition, if someone knows of an effective way to turn such things aside at less cost than be simply leaving them to tor to deal with, I'd love to know about it, too, though I suspect there may be no such method. Thanks in advance for any relevant information! Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 2

One of my relays does not get a "consensus weight" value and is not in the list.
by failing.flyaway443＠mailer.me 30 Aug '22

30 Aug '22

Hello everyone, I have a question about another relay I deployed a few days ago. This time I set up two relays on a server with only one IP address, almost simultaneously. They are "Infinity1" and "Infinity2". I kept looking at the Relay Search to see how everything was going, and Infinity1 already has a consensus weight of 36000, but Infinity2's value is still at 1. So I looked at the big consensus list, and sure enough, it only has Infinity1 in it. Could it be that the Directory Authorities do not accept Infinity2 for some reason, or should I just be patient a bit longer? I also noticed that Infinity1 is already moving an average of 15Mb/s of traffic, while Infinity2 is still hanging around in the Kb range. Of course I did everything correctly, MyFamily and ContactInfo are set. Does anyone here know what this could be? The fingerprint of Infinity2 is 9F459D4756AA61D7ED05D000EA4C757FA19AC401. Thank you everyone for taking the time to think about this for a moment and have a great day to you all! Best

1 1

OOM Bytes Cell
by Nyasaki Server 29 Aug '22

29 Aug '22

Hi, my node is running for a while now, today I noticed that the cell oom bytes has risen, which never happened before. Is this concerning? What does the cell value mean? Im thankful for every input! BR Nyasaki

1 0

Closing relay
by Ole Rydahl 29 Aug '22

29 Aug '22

Since 2014 I have run a non-exit relay at my premises. However ultimo July the system load increased abruptly. Idle-cpu -typically 60-70% - dropped to 30%, _and_ with frequent drops to 0! I reduced the max bandwidth to 1.2 Mbytes. That reduces the load somewhat but still with frequent spikes where the idle-cpu hits 0 and I get the "relay too slow" indication. Any suggestions? /Ole Rydahl https://metrics.torproject.org/rs.html#details/CE1FD7659F2DFE92B883083C0C6C9 74616D17F3D

2 1

Overload
by sysmanager7 27 Aug '22

27 Aug '22

Another New one: 19:01:09 [NOTICE] General overload -> Ntor dropped (176948) fraction 25.2668% is above threshold of 0.5000% â 17:19:32 [WARN] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth â config option or choosing a more restricted exit policy. Any Ideas?? What is the syntax for MaxAdvertisedBandwidth? Currently is: MaxAdvertisedBandwidth 3Mb Sysmanager Sent with [Proton Mail](https://proton.me/) secure email.

1 0

missing IPv6 close events
by Toralf Förster 27 Aug '22

27 Aug '22

Playing with Python and Stem I wrote a script to monitor the ORStatus.CLOSED event reasons [1]. A helper script [2] gives statistics from those data. From the last 2 days I got: $> orstatus-stats.sh /tmp/orstatus.29051 CONNECTRESET 6197 CONNECTRESET 13214 DONE 18769 IOERROR 58 NOROUTE 1661 TIMEOUT 2562 TLS_ERROR 42461 I was wondering if it is expected that DONE is just a 1/4 of all reasons. And I do wonder why all events are IPv4 only. [1] https://github.com/toralf/torutils/blob/main/orstatus.py [2] https://github.com/toralf/torutils/blob/main/orstatus-stats.sh -- Toralf

1 0

Warn:
by sysmanager7 24 Aug '22

24 Aug '22

I got the below message on my relay #2. It's been in operation for a year and a half. First time I've ever got one of these. 0re7:26:40 [WARN] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [505 similar message(s) suppssed in last 57840 seconds] OK > Both relays operate on Digital Ocean Droplets Bandwidth on both 2 MBs Burst 3MBs both relays have the same settings NEITHER is an exit: ExitPolicy reject I see relay #2 has been restarted. Last eve it had been up four days. As of this writing just over 2 hours. Or is this another way to muck up a relay? Sysmanager Sent with [Proton Mail](https://proton.me/) secure email.

1 0

We need much more bridges with obfs4 and iat-mode set to 1 or 2..barely can't find any.
by elise.toradin＠web.de 24 Aug '22

24 Aug '22

4 3

Strange entries in notices.log
by toritdown 23 Aug '22

23 Aug '22

I am suddenly finding numerous entries in my /var/log/tor/notices log that look like this: Aug 22 01:21:46.000 [warn] Unable to store router descriptor Aug 22 01:21:46.000 [warn] Error writing to "/var/lib/tor/cached-descriptors.new": No space left on device What does this mean? What do I need to do about? Sent with [Proton Mail](https://proton.me/) secure email.

4 3

Relays spamming my OR port
by Logforme 19 Aug '22

19 Aug '22

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 I have tried to mitigate the current DoS by implemented connection limits in my iptables using Toralf's template: More than 25 connection during 10 mins and you end up on my naughty list. Lots of connection attempts from the naughty list dropped but still my relay gets "overloaded" However, I have noticed that a few relays also end up on the naughty list, and I wonder how that can happen. My understanding is that a relay will only open 1 connection to another relay so should therefore never end up on the list. Correct? D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent naughty boy. Maybe these relays disconnect and reconnect to my relay frequently due to network issues (effect from the DoS?) or from not having enough connections available on the router? I guess my real question is if these connections are legit and I'm hurting the Tor network by using connection limits?

4 10

Metrics falsely showing my relay as offline
by Eddie 19 Aug '22

19 Aug '22

I have 1 relay (40D13096BBD11AF198CE61DEE4EAECCE5472F2E7) that according to the metrics is always bouncing between online and offline, sometimes multiple times per day. The logs show it running the whole time and when the metrics also show it running, the uptime continues to increase correctly. This hasn't always been the case, as the history shows this didn't happen prior to around June based on the guard flag usage. This relay is hosted at AWS if that makes any difference. Should I care about this, because the relay is running correctly. It's just that it never gets the stable (long running) and guard flags any more because of this yo-yo effect, which I'm sure is affecting how the relay is allocated circuits. I do have another relay (E823B5F000835A669E902EBAE5ECCB9A324F46C9) that sometimes exhibits the same issues, but to a much lesser extent. Like it will show offline (maybe) once a month for a very short period and any flags lost are quickly regained.

2 2

[New Initiative] Tor Weather: Improving the Tor Weather
by Sarthik Gupta 18 Aug '22

18 Aug '22

Hello everyone, As we all know, nodes are the building blocks of the tor-network. More often than not these nodes require some maintenance, which could be in the form of software upgrades, troubleshooting issues, rebooting the relays in case of failures, etc. As of today, if any relay disappears from the tor-network, no one will know. Tor-Weather aims at solving this by creating a notification service which relay operators can subscribe to in order to get various types of updates for their relays. The tor-weather service will offer a plethora of notifications options for the relays. These include, the node being down, running on EOL/Outdated version, losing a flag, ranking in top 20/50/100, etc. These notifications can be subscribed & customized by the relay operators to fit their needs using a web-frontend. Folks interested in the project can refer this <https://lists.torproject.org/pipermail/tor-dev/2022-May/014734.html> thread in the tor-dev mailing list for regular updates. Suggestions are always welcomed! Please reach out to us in irc (#tor-dev) for any ideas, questions, or suggestions you might have. Thanks, Sarthik Gupta

4 6

easy way to test my exit policy
by Tom Yates 18 Aug '22

18 Aug '22

i've been grumbled at in a way that makes me want to validate my exit policy before dismissing the grumble. is there any easy way to check that, as a tor client, i can't make an outbound connection from my tor server to a particular port on a particular server? i suppose i'm asking if there's a tor-aware telnet, or equivalent. how do people test their exit policies? -- Tom Yates - https://www.teaparty.net

2 2

tor relay over wifi
by andrew reid 17 Aug '22

17 Aug '22

hi i am running a tor relay on an old phone over wifi. is this a bad idea ?

1 0

Have you experienced DDoS?
by Viktor Nikolov 15 Aug '22

15 Aug '22

Hi! My provider of server housing disconneded today at about 12:00 CET my server running two guard relays because of "very strong attack; top traffic was in tens of GBps and threatened both our internal network infrastructure, as well as the availability of the provided services for other customers; number of network flows according to monitoring was between 3-4M." My normal traffic is max. 600 Mbps and few tens of thousands connections. They will come back to me during the office hours of Monday. :-( Was somebody else also subject to DDoS today? Viktor

3 2

Flags gone after restart
by andrew reid 11 Aug '22

11 Aug '22

Hey there, I am running a tor relay off an old samsung phone. When I first started the relay, my observed bandwidth was around 4.5MB/s. It was running for around 7 days and had the stable and HSdir flag. After a few problems with IP6 and being overloaded (thought this was a problem on my end, not a DDoS attack) I restarted the phone and edited the config file to take away IPv6. It has now been running for 7 days again but my observed bandwidth is only 1.6MB/s now and I still haven't gotten the stable and HSdir flag back. How long would this take or is it just a problem on my end ? and for the bandwidth, my connection is still the same and hasn't changed. Is this just something that takes time to come back like the flags. This is my first relay so I would like to understand a bit more. Thank you

2 1

Refuse Guard flag
by Eldalië 11 Aug '22

11 Aug '22

Hello there. I have been running my (non-exit) relay without issues for some months. Recently I noticed that my ISP started to reset my IP a few hours after the node gets the Guard flag, thus making it lose such a flag (as well as Stable and HSDir). I am not sure if the Guard flag is the real cause, but it is the only condition that is verified always and only right before I get a new IP. Is there a way I can keep my node running with the same settings but preventing it from becoming a guard, to investigate if the flag is the real cause? Thanks, Eldalië -- Eldalië My private key is attached. Please, use it and provide me yours!

3 2

How useful are bridges on ports other than 80 and 443
by Eddie 10 Aug '22

10 Aug '22

Unfortunately I've had to shut down my home based tor relay because my wife's employer is mis-categorising it as an exit node, instead of the middle/guard that it really is. So, until she retires, in a few months, that relay will now be silent after about 5-years running (all of which her having the same employer. Go figure). So, I thought in the meantime I'd run a couple of tor bridges, as my IP should now be clear of any published tor node lists. But I do need to leave ports 80 and 443 open for "normal" HTTP(S) traffic, which I know are the recommended bridge ports as they raise the least suspicion. Are there any other ports that folks might suggest I use that would get enough traffic and not be blocked by a simple firewall. I also run an internal mail server, so all those ports are off limits as well. Cheers.

1 0

Setting a bridge to automatically change IP adresses
by Keifer Bly 10 Aug '22

10 Aug '22

3 3