- network-health - lists.torproject.org

Calling the Network Health Team: Your Expertise Can Transform Tor!
by Ravi Kumar 25 Jul '23

25 Jul '23

Dear Network Health Team, I hope this email finds you well! As a valued member of the Tor community, your expertise and insights hold immense importance in shaping the future of our network. Currently, I am conducting an MSc Dissertation study focused on understanding the significance of Tor relay updates and a proposed automatic update mechanism from a developer's perspective. Your input will play a vital role in advancing the network's health and enhancing the overall Tor experience for millions of users worldwide. Your time and effort are deeply appreciated, and I assure you that your responses will be treated with the utmost care and confidentiality. The survey is thoughtfully designed to be completed in just 10 minutes and will be live until the 5th of August. Your contribution to this transformative research will not only benefit the Tor community but also further our commitment to privacy and security on the internet. I kindly request your participation in this study. Your unique insights and experiences will make a significant impact on the development of the Tor network. If you have any questions or need further information, please don't hesitate to contact me at S2450888(a)ed.ac.uk. Your feedback and queries are always welcomed and valued. Let's work together to create a stronger, more secure online world for all users of Tor. To access the survey, please click on the following link: https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc… [https://cryptpad.fr/customize/images/opengraph_preview/og-form.png]<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc…> Encrypted Form<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc…> CryptPad: end-to-end encrypted collaboration suite cryptpad.fr Thank you for your time and consideration. Best regards, Ravi Kumar S2450888(a)ed.ac.uk The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

1 0

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