- network-health - lists.torproject.org

Middle Relays.
by dawn.belle.flood 08 Feb '23

08 Feb '23

Good Day, I have run a middle Tor relay for many years. I wish that the Tor Project would stop publishing the IP addresses of middle relays. Such will make the Tor Network more secure; plus, my home IP address is being blacklisted as being a VPN, proxy, malicious, etc. Thank you, Dawn

2 1

When will Relay Search show more than 2, 000 bridges?
by Victor Leser 09 Jan '23

09 Jan '23

Hello. When I do a Tor Metrics Advanced Search for all running bridges, (type:bridge running:true), I see the following comment above the results. __________----------________---------- Relay Search type:bridge running:true Too many matches! The current version of Relay Search does not support a result set greater than 2000 and only displays the first 2000 hits. This is due to some performance issues in rendering large results sets in JavaScript. Future versions will hopefully manage to overcome this issue. _______---------________-------- I believe that it is possible that some bridges may be shown as not working by Relay Search because of the 2,000 bridge limit to the report on working bridges, rather than the bridge being faulty. Can you please tell me when a version which is not limited to 2,000 hits will be available? Given the large increase in the number of bridges since 2021, I presume that work on this new version may have started, and would like to know when it will be completed. I have searched for an answer online but not found anything. I may not be looking in the right place, so I thought that I should ask you the question as suggested in the section on "Contact". With thanks in advance, Victor Leser Proton Mail = secure email = courriel sécurisé

4 3

Date for Relay search version showing more than 2, 000 hits
by Victor Leser 02 Jan '23

02 Jan '23

When I do a Tor Metrics Advanced Search for all running bridges, I see the following comment above the results. __________----------________---------- Relay Search type:bridge running:true Too many matches! The current version of Relay Search does not support a result set greater than 2000 and only displays the first 2000 hits. This is due to some performance issues in rendering large results sets in JavaScript. Future versions will hopefully manage to overcome this issue. _______---------________-------- Can you tell me when a version which is not limited to 2,000 hits will be available? I have searched for an answer online but not found anything. With thanks in advance Sent from ProtonMail mobile

1 0

How is a relay's uptime determined?
by arf20 21 Dec '22

21 Dec '22

Hello there, I run a tor middle relay, and last night I restarted the service due to an update. Then, looking up the relay in the Tor site, it looks like I lost all the uptime and flags. A bit annoying since I have had the server down for several minutes without consequences in other times. I was 5 days away from the t-shirt :( I was just wondering under what circumstances the relay's uptime is reset, if possible. Thanks. -- arf20

2 2

Converter of Tor metrics data to Parquet, and some other stuff
by Thomas Lörtsch 19 Dec '22

19 Dec '22

Hi, I was working as a volunteer with the Metrics team under the auspices of Karsten Loesing. He ended that collaboration in 2016 in a rather unfortunate way and I have no idea if he ever looked at my code again. I do still have the code that I worked on and I still think it has some value: the main contribution is a converter from Metrics’ own data format to Parquet. Parquet is a data format optimized for Big Data analytics in tools like Spark and related technologies e.g. Jupyter notebooks. I also did spend a lot of time in understanding, organizing and writing down what all the data points that Metrics collects mean, how they correlate etc. In the end all this was meant to drive a fantastic visualization of Tor data, but that part did never materialize. However, the decision for Parquet and Spark was not trivial back then, but seems to have proven to be a good one since both still seem to be strong offerings in the Big Data space. I haven’t since worked on the code, it never had a proper test suite and Metrics’ data formats have probably evolved from then. Also, I haven’t followed the work of the Metrics team and maybe you have developed something much better in the meantime. Back then, six years ago, most aggregation was done in Postgres, and Spark would most probably have outperformed the Postgres RDBMS easily. By the way, I just remember I also developed a giant relational schema for all of Metrics’ data... Anyway, if any of this sounds interesting to you please contact me (off-list, as I don’t follow the lists anymore). I will be happy to provide you access to the GitLab repo, spend a few hours to get myself up to speed again on what I was doing back then, and help you evaluate if it may be of any value to you. I will however not work on the code again in earnest, as after Karsten kicked me out I completely switched back to what I was doing before I joined Tor. Best, Thomas

1 0

Re: [network-health] Relay Overloaded
by Georg Koppen 09 Nov '22

09 Nov '22

Tor Operator: > Hello Georg, > > The relay fingerprint is: > > 9A156D69784669874456A67E7210F80867E3F1FC > > > Yes, I have configured the maximum bandwidth that I can provide to 90.00 > MiB/s approximately and i'm interested in buying more bandwidth if all is > consumed. > > For now the problem is solved by raising the swap memory from 100mb to 8gb, > restarting the server and the TOR service, maybe that can help in future > DDoS attacks that may reach my node. Right. Raising the swap limit seemed like another solid guess given the screenshots you sent, nice. > Taking advantage of this communication, I am not sure why TOR cannot > consume more bandwidth. The maximum it can consume in bursts is 24.00 MiB/s > but in TOR Metrics I can only see a bandwidth of 4.76 MiB/s. > > It is likely that the reason that more bandwidth cannot be consumed, is > that the nodes are mostly in Europe and the communication latency to South > America is not efficient to build circuits? No, the value you see in Advertised Bandwidth is not related to any measurements being done (to estimate your bandwidth) nor related to build times of circuits. It's the minimum of what you configured for your relay and recently observed traffic. So, it *could* be that you are affected by data transfer bottlenecks from South America to, say, Europe or the US but that's hard to say. Either way, having a relay where you have it right now is highly valuable as we get more diversity into our network that way. So, please keep it there if possible, regardless whether you currently max out your bw or not. Thanks for running a relay, Georg > Thanks for your reply. > > El mar, 8 nov 2022 a la(s) 04:30, Georg Koppen (gk(a)torproject.org) escribió: > >> Tor Operator: >>> Hello, >>> My relay is continuously overloaded, so I have activated MetricsPort to >>> obtain information. >> >> Great! Which relay is that? >> >>> According to the documentation it seems to be a CPU problem, but the CPU >>> consumption level has enough resources and at the RAM level I also have >>> available resources. >>> >>> Can you help to solve the problem? I can provide up to 90Mbps of >> bandwidth >>> but it seems unable to consume all the bandwidth. The server runs on a >>> RaspBerry PI 4 - 8GB - 4CPU >> >> Have you tested the MaxAdvertisedBandwidth option to check whether it >> solves your problem? Note that Tor is to a large extent single-threaded >> and it's enough to get one burst of dropped ntor onionskins to get the >> overload flag for about 24h. >> >> Does the issue still show up? Since 10/28 it seems our DoS situation >> improved greatly (although no one knows how long this will last). >> >> Thanks, >> Georg >> >>> [image: imagen.png] >>> >>> [image: imagen.png] >>> [image: imagen.png] >>> >>> # HELP tor_relay_load_oom_bytes_total Total number of bytes the OOM has >>> freed by subsystem >>> # TYPE tor_relay_load_oom_bytes_total counter >>> tor_relay_load_oom_bytes_total{subsys="cell"} 0 >>> tor_relay_load_oom_bytes_total{subsys="dns"} 0 >>> tor_relay_load_oom_bytes_total{subsys="geoip"} 0 >>> tor_relay_load_oom_bytes_total{subsys="hsdir"} 0 >>> # HELP tor_relay_load_global_rate_limit_reached_total Total number of >>> global connection bucket limit reached >>> # TYPE tor_relay_load_global_rate_limit_reached_total counter >>> tor_relay_load_global_rate_limit_reached_total{side="read"} 0 >>> tor_relay_load_global_rate_limit_reached_total{side="write"} 0 >>> # HELP tor_relay_load_socket_total Total number of sockets >>> # TYPE tor_relay_load_socket_total gauge >>> tor_relay_load_socket_total{state="opened"} 4997 >>> tor_relay_load_socket_total 65504 >>> # HELP tor_relay_load_onionskins_total Total number of onionskins handled >>> # TYPE tor_relay_load_onionskins_total counter >>> tor_relay_load_onionskins_total{type="tap",action="processed"} 16911 >>> 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"} 13827588 >>> tor_relay_load_onionskins_total{type="ntor",action="dropped"} 179371 >>> tor_relay_load_onionskins_total{type="ntor_v3",action="processed"} >> 13827588 >>> tor_relay_load_onionskins_total{type="ntor_v3",action="dropped"} 179371 >>> # HELP tor_relay_exit_dns_query_total Total number of DNS queries done by >>> this relay >>> # TYPE tor_relay_exit_dns_query_total counter >>> tor_relay_exit_dns_query_total 0 >>> # HELP tor_relay_exit_dns_error_total Total number of DNS errors >>> encountered by this relay >>> # TYPE tor_relay_exit_dns_error_total counter >>> tor_relay_exit_dns_error_total{reason="success"} 0 >>> tor_relay_exit_dns_error_total{reason="format"} 0 >>> tor_relay_exit_dns_error_total{reason="serverfailed"} 0 >>> tor_relay_exit_dns_error_total{reason="notexist"} 0 >>> tor_relay_exit_dns_error_total{reason="notimpl"} 0 >>> tor_relay_exit_dns_error_total{reason="refused"} 0 >>> tor_relay_exit_dns_error_total{reason="truncated"} 0 >>> tor_relay_exit_dns_error_total{reason="unknown"} 0 >>> tor_relay_exit_dns_error_total{reason="tor_timeout"} 0 >>> tor_relay_exit_dns_error_total{reason="shutdown"} 0 >>> tor_relay_exit_dns_error_total{reason="cancel"} 0 >>> tor_relay_exit_dns_error_total{reason="nodata"} 0 >>> # HELP tor_relay_load_tcp_exhaustion_total Total number of times we ran >> out >>> of TCP ports >>> # TYPE tor_relay_load_tcp_exhaustion_total counter >>> tor_relay_load_tcp_exhaustion_total 0 >>> >> >> >

1 0

needs help
by Nathan Jones 19 Oct '22

19 Oct '22

I am getting this in my new relay’s log 02:18:29 [NOTICE] No circuits are opened. Relaxed timeout for circuit 225 (a Testing circuit 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. [5 similar message(s) suppressed in last 8940 seconds] tor relays uptime is around 24 hours. Is this a bad notice? will my relay still work fine?

2 1

Protect E-Mail addresses on metrics.torproject.org/rs.html
by gg03gnk20fn82 07 Jun '22

07 Jun '22

Greetings This E-mail address (until sending this email) is publicly visible only on the metrics site of the torproject and I am getting already a good amount of spam. Maybe a protection like some of the suggestions https://www.ionos.com/digitalguide/e-mail/e-mail-security/protecting-your-e… would maybe reduce the amount? Would be a sympathetic improvement. Thx

2 1

exit-address related questions
by Star East 22 Mar '22

22 Mar '22

Hi Team, Good evening. Please refer below TOR exit node list : https://check.torproject.org/exit-addresses. Which has following fields: ExitNode 63BA28370F543D175173E414D5450590D73E22DC Published 2010-12-28 07:35:55 LastStatus 2010-12-28 08:10:11 ExitAddress 91.102.152.236 2010-12-28 07:10:30 Based on documentation I found here : https://metrics.torproject.org/collector.html#type-tordnsel the above fields have the below meaning : ExitNode - fingerprint of the exit relay node Published - Descriptor publishing time which 07:35:55 LastStatus - relay node was contained in a version 2 network status made at 08:10:11 ExitAddress - ip address for exit node 91.102.152.236 was found in a test performed at 07:10:30. However, I am not clear on what is the meaning of timings mentioned in LastStatus and ExitAddress fields, if you can please explain that or point me to right documentation ?. Also apart from exit-address and torbulkexitlist is there any other list which mentions last seen time or has more detailed metadata about exit list nodes ? . Kindly answer the above questions. Thanks, Andrew

2 1

Bridge status
by Bruno Grossmann 21 Mar '22

21 Mar '22

Hello, I have installed a bridge in December 2021. It has been running seamlessly - until recently. For the last week or so, when I check the status page, it says it is down. Yet, when I check on the server, it seems to be running fine (see output below). Is it an issue with the bridge checking mechanism or is there a real issue with my bridge? In other words, what information would I be looking for to ensure my bridge is up? [root@li1228-97 ~]# systemctl status tor-master.service ● tor-master.service - Anonymizing overlay network for TCP (multi-instance master) Loaded: loaded (/usr/lib/systemd/system/tor-master.service; disabled; vendor preset: disabled) Active: active (exited) since Wed 2022-03-16 12:20:43 UTC; 22h ago Process: 19224 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 19224 (code=exited, status=0/SUCCESS) Tasks: 0 CGroup: /system.slice/tor-master.service Mar 16 12:20:43 li1228-97 systemd[1]: Stopped Anonymizing overlay network for TCP (multi-instance master). Mar 16 12:20:43 li1228-97 systemd[1]: Stopping Anonymizing overlay network for TCP (multi-instance master)... Mar 16 12:20:43 li1228-97 systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance master)... Mar 16 12:20:43 li1228-97 systemd[1]: Started Anonymizing overlay network for TCP (multi-instance master). [root@li1228-97 ~]# systemctl status -l tor ● tor.service - Anonymizing overlay network for TCP Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2022-03-16 12:21:13 UTC; 22h ago Process: 19238 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS) Main PID: 19240 (tor) Tasks: 9 CGroup: /system.slice/tor.service ├─19240 /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc └─19242 /usr/local/bin/obfs4proxy Mar 17 06:21:43 li1228-97 Tor[19240]: Heartbeat: In the last 6 hours, I have seen 0 unique clients. Mar 17 06:41:44 li1228-97 Tor[19240]: Auto-discovered IPv6 address [2600:3c03::73f0:da93:352a:f688]:26250 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] Mar 17 07:34:47 li1228-97 Tor[19240]: No circuits are opened. Relaxed timeout for circuit 673 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. [7 similar message(s) suppressed in last 10020 seconds] Mar 17 07:41:44 li1228-97 Tor[19240]: Auto-discovered IPv6 address [2600:3c03::73f0:da93:352a:f688]:26250 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] Mar 17 08:41:44 li1228-97 Tor[19240]: Auto-discovered IPv6 address [2600:3c03::73f0:da93:352a:f688]:26250 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] Mar 17 09:24:48 li1228-97 Tor[19240]: No circuits are opened. Relaxed timeout for circuit 718 (a Testing circuit 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. [2 similar message(s) suppressed in last 6600 seconds] Mar 17 09:41:44 li1228-97 Tor[19240]: Auto-discovered IPv6 address [2600:3c03::73f0:da93:352a:f688]:26250 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] Mar 17 09:51:50 li1228-97 Tor[19240]: Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 462 buildtimes. Mar 17 10:41:44 li1228-97 Tor[19240]: Auto-discovered IPv6 address [2600:3c03::73f0:da93:352a:f688]:26250 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] Mar 17 10:45:46 li1228-97 Tor[19240]: No circuits are opened. Relaxed timeout for circuit 850 (a Testing circuit 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. [1 similar message(s) suppressed in last 4860 seconds]

2 1