- tor-relays - lists.torproject.org

General overload -> DNS timeouts
by Intrepid Ibex 07 Jan '22

07 Jan '22

Hi everybody, I am new to tor (as server operator) and try to support the network by operating an exit node. Machine is running Ubuntu 20.04 - Tor 0.4.6.8. nyx is giving me a notive every 10 minutes or so: [NOTICE] General overload -> DNS timeouts (6) fraction 1.4742% is above threshold of 1.0000% DNS on this machine however works perfectly. I told my tor browser to use my specific exit node, everything works fine. Node is running since 4 days now. Load is as expected. Thanks in advance for any help! Ibex \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

13 25

Tor relay struggling with circuit creation (CPU Limit)
by GANDI24325_TOR 06 Jan '22

06 Jan '22

Hi Tor relay community, I have recently made a new tor relay, and all is going well however I use NYX to mointor it and over the last day it has been giving the warning message seen below in the nyx mointor, the relay had been running fine for it's first 4 days of life but now shows this message for nealry 30 hours now (scrolling through logs) Also the nyx mointor shows a CPU usage of 80-90% so I know this is the limiting factor and have no issue with it as this server is just free VPS that I am donating so ideally would like it to pump out as much data in/out as possible, but my question is, Do I need to change my torrc to fix this error or will the tor network realize overtime how much traffic is best for this node? Useful information: https://metrics.torproject.org/rs.html#details/448E2528A4AC58A7531EC950AAF0…: GANDI24325second the relay in quesiton, with this website showing everything as fine Family: https://metrics.torproject.org/rs.html#search/family:BC77562EF192F0A580F54D…: the other two relays are working fine Contact info: GANDI24325_TOR [at] protonmail (dot) com Addtional info: If I haven't provided enough infomation/if you want the torrc I can help Thanks in advance for any help Warning messages: 09:10:10 [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. │ [2012 similar message(s) suppressed in last 120 seconds] │ 09:09:09 [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. │ [1467 similar message(s) suppressed in last 60 seconds] │ 09:08:08 [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. │ [628 similar message(s) suppressed in last 60 seconds] │ 09:07:08 [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. │ [518 similar message(s) suppressed in last 120 seconds] │ 09:05:57 [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. │ [10092 similar message(s) suppressed in last 2820 seconds] │ 08:19:05 [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. │ [13039 similar message(s) suppressed in last 120 seconds] │ 08:18:04 [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. │ [11034 similar message(s) suppressed in last 60 seconds] │ 08:17:04 [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. ─┘ [7335 similar message(s) suppressed in last 60 seconds]

2 1

Some questions about the uptime requirement
by David Hu 05 Jan '22

05 Jan '22

Hello Tor Relay operators, I am hosting a rather new Tor relay and my uptime is only about 13 hours, while I would like to contribute to Tor by continuing as a relay (NOT an exit one though because of frequent abuse of exit relays and my ISP won't allow it). My question is that I am going to another location for vacation for 3 days and my relay would probably not be up during that time. Does that forfeit my chance to be chosen by clients forever? Thank you! Regards, David

2 1

TOR Metrics showing relay as down but logs show it is apparently active
by Tor Geheimschreiber 05 Jan '22

05 Jan '22

Not sure if this is the correct list on which to ask but a new node created just over 7 days ago is now being shown on Tor Metrics (atlas.torproject.org) as being down. However local logs show heartbeat activity and some directory activity. A port scan of the IP address shows: -- cut here Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-05 14:22 GMT Nmap scan report for [redacted] Host is up (0.018s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp filtered ssh 8085/tcp open unknown 9001/tcp open tor-orport Nmap done: 1 IP address (1 host up) scanned in 1.27 seconds -- cut here /var/log/tor/notices.log shows: -- cut here Jan 05 00:00:34.000 [notice] Tor 0.4.6.9 opening new log file. Jan 05 02:45:49.000 [notice] Heartbeat: Tor's uptime is 6 days 8:42 hours, with 3189 circuits open. I've sent 337.09 GB and received 332.67 GB. I've received 64461 connections on IPv4 and 13628 on IPv6. I've made 106191 connections with IPv4 and 36300 with IPv6. Jan 05 02:45:49.000 [notice] While not bootstrapping, fetched this many bytes: 104491070 (server descriptor fetch); 5940 (server descriptor upload); 11006113 (consensus network-status fetch); 1211313 (microdescriptor fetch) Jan 05 02:45:49.000 [notice] Circuit handshake stats since last time: 632/632 TAP, 172332/172332 NTor. Jan 05 02:45:49.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 17 v2 connections; initiated 0 and received 0 v3 connections; initiated 2 and received 11816 v4 connections; initiated 113167 and received 63288 v5 connections. Jan 05 02:45:49.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Jan 05 08:45:49.000 [notice] Heartbeat: Tor's uptime is 6 days 14:42 hours, with 131 circuits open. I've sent 341.77 GB and received 337.28 GB. I've received 66326 connections on IPv4 and 13652 on IPv6. I've made 108563 connections with IPv4 and 37174 with IPv6. Jan 05 08:45:49.000 [notice] While not bootstrapping, fetched this many bytes: 108020255 (server descriptor fetch); 8064 (server descriptor upload); 11383626 (consensus network-status fetch); 1232744 (microdescriptor fetch) Jan 05 08:45:49.000 [notice] Circuit handshake stats since last time: 193/193 TAP, 57579/57579 NTor. Jan 05 08:45:49.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 17 v2 connections; initiated 0 and received 0 v3 connections; initiated 3 and received 11912 v4 connections; initiated 115806 and received 65008 v5 connections. Jan 05 08:45:49.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. -- cut here Any pointers on how to investigate the problem further would be welcome. Thanks, Quentin

2 1

Maybe the next step in russian Tor discrimination
by Tor Relays 03 Jan '22

03 Jan '22

Hello, i have a relay at profitserver.ru at their Chelyabinsk location and recently the relay fell out of the consensus. I can ping all authorities with IPv4 and IPv6 and torproject.org is not blocked. I opened the ControlPort and tried to manually create circuits to the authorities. extendcircuit 0 authoritynickname getinfo circuit-status I observed that i can successfully create circuits to no more than three authorities and it seems to change to which authorities i can create circuits. The unsuccessful circuits stay in EXTENDED but never reach BUILT until Tor gives up eventually. Currently no other of my russian relays are affected. I am not an expert with the ControlPort but i hope this is proving what i tried to prove. Here is the conversation with the support: me: Hello, I am running a (non-exit) Tor relay on the VPS and it stopped working a few weeks ago. I can ping the Tor authorities IP addresses but when i try to manually create a Tor circuit it seems to timeout 6 out of 9 times which indicates some blocking attempts on your (or your upstream providers) side. I have a couple of other Tor relays in russia and i have never seen routinely failing manually created circuits to the Tor authorities. Do you block Tor or do you otherwise mess with Tor traffic? support agent: Hello, i can't say something about TOR network, now. We have black box from government, which can control traffic, and perhaps block TOR. Ourselves don't block TOR me: Thanks for your answer. The TSPU from Roskomnadzor that is doing Deep Packet Inspection? I feel with you and all the russian citizens... :( Good luck support agent: Maybe it's a black box If this is indeed their blackbox messing with Tor traffic then it is quite subtile because it does not block torproject.org and pings to the authorities are going through. The relay suddenly was online for one consensus in the last weeks and i can still use it when i manually set it as a Guard in my Tor client. So if you run a relay in russia and you experience weird stuff with it then you may not only want to check if you can reach the authorities by ping but you may want to try to manually craft a circuit to all of them. Hope that helps anyone Cheers

5 4

running a bridge
by carl box 02 Jan '22

02 Jan '22

4 3

Relay operators meetup @ rC3
by Stefan Leibfarth 29 Dec '21

29 Dec '21

Greetings relay operators, the annual Tor relay operators meetup will be tomorrow (28th) at 2200 UTC+1. No rC3 ticket required, I'll post the public link here as soon as it's available. Looking forward to meeting you Leibi

4 4

[Censorship in Russia] More of my bridges got blocked
by spaceoddity＠disroot.org 29 Dec '21

29 Dec '21

Hello Tor people, just me chipping in about recent event. Today, I discovered that somewhere around Dec, 22, all three of my recently launched bridges have been censored on at least one network (MegaFon Moscow AS25159). Metrics show a drastic traffic drop in the range of Dec, 21-23 for all three bridges. Investigating further, I discovered (using tcptraceroute/nc) that all three hosts started responding with RSTs to all of their open ports (not only bridge ports but SSH and other recently opened ports too). NATd source IP address was unchanged from my usual one in every case. One of the bridges had distribution method set to HTTPS, and the other two were distributed via Moat. All ran recent Tor 0.4.6.8 Docker image. NB: One of the bridges has incorrect 'First seen' date on the metrics portal - it displays '2021-12-25' despite being launched several days prior. To summarize: 1. Bridge blocking happens via the common 'fast RST' method 2. It happened relatively quickly (all bridges are less than 10 days uptime by now). 3. Somehow, all three of my recently launched bridges were blacklisted despite using different ASs/hosters/countries for each. Is it a coincidence, or it's because Moat prefers to hand out newer bridges first, or due to something else entirely? Also, I can not rule out that some step in my distribution chain was compromised -- I gave out these bridges privately to a few friends. -- Best regards, Space Oddity.

3 4

Incorrect "first seen" info
by a tor op 28 Dec '21

28 Dec '21

I notice that the "first seen" info on my obfs4 bridge status page on tor atlas / metrics all of a sudden is incorrect, by years. Not sure if it's something that introduced itself with latest update or what. The various graphs on traffic and users are still correct through. A tor op

3 3

[Censorship in Russia] Make HTTPS/Moat captcha more complex?
by spaceoddity＠disroot.org 27 Dec '21

27 Dec '21

Hi there. I was thinking, what could be the ways Russian authorities could get bridges to block. One of the obvious ways to do this is to grab bridges from Moat/HTTPS, but since that would require solving a captcha, this would indicate its strength is insufficient, or they are able to crowdsource/mass solve somehow. The other thought is an attack via email. Can we do something with it, what do you think? -- Best regards, Space Oddity.

8 10