- network-health - lists.torproject.org

New Relay although stats show data for one year
by Stephan 15 Jan '24

15 Jan '24

Hi tor-team, I just noticed that my relay (https://metrics.torproject.org/rs.html#details/B0AD9C3F75C994CEEB9CFC1BD698…) is marked as "newer than 2 weeks" although the graphs show data since 2023-03 and I have not generated a new fingerprint actively. The fingerprint file on the server also did not change (created at 2023-03-06). There are more inconsistencies: First Seen 2024-01-10 16:00:00 (1 day 7 minute and 56 seconds) Last Restarted 2024-01-06 04:02:43 Do you have an idea how this might be? I also noticed that the server restarted itself after > 170 days, but this might be a problem on my side. Thanks in advance. Kind regards, Stephan

2 1

[To the maintainers of Tor Metrics] Metrics showing erroneous data for my two relays, can somebody responsible please take a look at the issue?
by George Hartley 11 Jan '24

11 Jan '24

Hello, for about 3 months I have been hosting two Tor relays: https://metrics.torproject.org/rs.html#details/AF42E6C77196A37F041A1A1E953E… https://metrics.torproject.org/rs.html#details/7F7D1A5BE88FA7C9358955705AE7… After doing system maintenance (mainly upgrading packages), slightly adjusting my "BandwidthRate" and "BandwidthBurst" for both relays and then rebooting the server earlier, the guard relay now shows the following on Metrics, even though the graphs still show the old, correct data: > The first time that this relay was seen in the consensus: 2024-01-10 16:00:00 (8 hours 57 minutes and 21 seconds) This is even though metrics shows an uptime of almost 16 hours?! The fingerprints did not change according to both the metrics page, and the Tor log. I did not delete or mess with each relays DataDirectory or the secret keys. I have a MyFamily setting in both relays configs: > MyFamily $AF42E6C77196A37F041A1A1E953E51B4656BDC1B, $7F7D1A5BE88FA7C9358955705AE7AFA61EEDA2B0 Yet the relays don't show up as being in a family, and Metrics doesn't at all display the other relay counterpart as a family member when visiting the page for the guard or exit. There is also no line in the relays journal (from journalctl -u tor@guard) indicating that the guard relay is new to the network, and it retains its older flags. This only seems to affect my guard relay, the exit metrics page shows mostly valid data, except for the missing family member. Since I did not change anything that would cause this, this is likely a bug with the metrics page, and I would encourage you to look into it. Thank you very much, George

1 1

Question about the number of services in Tor
by Ines Cardiel 18 Sep '23

18 Sep '23

Hi, I am contacting you to find out how I can figure out the total number of services exposed in the TOR network (not only web services like HTTP and HTTPS) that exist nowadays. Thanks! Inés

2 1

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

2024

2023

2022

2021

2020

2019

network-health