[tor-relays] Is the C tor client DoSStreamCreation aware?
Hello, is the upstream C tor client implementation (in git main) aware of the DoSStreamCreation consensus parameters and defaults thresholds and respects them to avoid triggering these exit relay defenses? If that is currently not the case yet, would it make sense to make it aware so it will never try to create streams at a higher rate? Even if it would be aware already, it would not self limit currently because the current consensus does not enable DoSStreamCreationEnabled. thanks! t...@appliedprivacy.net ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Webtunnel type bridge Tor Metrics
Maybe not directly related, but I've seen the same. The webtunnel bridge shows as functional on the bridges website and offline on the metrics website. It's been that way since I started running a webtunnel bridge last year. Could it be related to these settings? AssumeReachable 1 ORPort 127.0.0.1:auto On Wed, Apr 24, 2024 at 10:01 AM Hiro wrote: > Dionysios, all, > > This was an issue with rdsys and documents that weren't being synced to > the vm where collector.torproject.org lives. > > For details: > > https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/199 > > It should be solved now. > > Talk soon, > > -hiro > > On 4/22/24 22:13, Hiro wrote: > > Hey, > > > > On 4/20/24 17:40, Dionysios K. via tor-relays wrote: > >> Hello everyone, > >> > >> I recently switched from using obfs4 to Webtunnel from my bridge. > >> > >> Since the configuration change, the metrics website shows it as offline. > >> > >> The downtime displayed on the website is also odd as it shows a > >> random time each time I visit, such as "1 hour 14 minutes and 10 > >> seconds" or "2 hours 23 minutes and 30 seconds." > >> > >> However, the bridge is online. > >> > >> I am wondering if this is the correct behavior for the Webtunnel > >> protocol. > > > > The way the metrics website "decides" if a bridge is online is based > > on both the results of tests from the bridge authority and > > bridgestrap. If the bridge is working and receiving traffic, the > > reason why I can think it is marked as offline is that some of those > > tests is failing or we are failing to process the data correctly. > > > > It could also be that something is a bit off with the bridge > > configuration since you changed from obfs4 to webtunnel. You could > > start your investigation by looking at the logs on the machine, then > > you could check what the bridgestrap stats say about your bridge > > (https://collector.torproject.org/recent/bridgestrap/) and finally > > check the latest status > > (https://collector.torproject.org/recent/bridge-descriptors/statuses/). > > > > Let me know if this helps you. I could also check the bridge myself, > > you could open an issue on gitlab under the relay-search project > > (https://gitlab.torproject.org/tpo/network-health/metrics/relay-search), > > > or you can send me a private message (email or irc) with the hashed > > fingerprint and logs. > > > > Cheers, > > > > -hiro > > > > > >> > >> _______ > >> tor-relays mailing list > >> tor-relays@lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______ > > tor-relays mailing list > > tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Webtunnel type bridge Tor Metrics
Hey Hiro, The issue was solved for a few hours, it was the first time since I switched to webtunnel I saw my bridge online, but now it's again marked as offline. It's the same issue again. Apr 24, 2024 8:02:02 PM Hiro : > Dionysios, all, > > This was an issue with rdsys and documents that weren't being synced to the > vm where collector.torproject.org lives. > > For details: > > https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/199 > > It should be solved now. > > Talk soon, > > -hiro > > On 4/22/24 22:13, Hiro wrote: >> Hey, >> >> On 4/20/24 17:40, Dionysios K. via tor-relays wrote: >>> Hello everyone, >>> >>> I recently switched from using obfs4 to Webtunnel from my bridge. >>> >>> Since the configuration change, the metrics website shows it as offline. >>> >>> The downtime displayed on the website is also odd as it shows a random time >>> each time I visit, such as "1 hour 14 minutes and 10 seconds" or "2 hours >>> 23 minutes and 30 seconds." >>> >>> However, the bridge is online. >>> >>> I am wondering if this is the correct behavior for the Webtunnel protocol. >> >> The way the metrics website "decides" if a bridge is online is based on both >> the results of tests from the bridge authority and bridgestrap. If the >> bridge is working and receiving traffic, the reason why I can think it is >> marked as offline is that some of those tests is failing or we are failing >> to process the data correctly. >> >> It could also be that something is a bit off with the bridge configuration >> since you changed from obfs4 to webtunnel. You could start your >> investigation by looking at the logs on the machine, then you could check >> what the bridgestrap stats say about your bridge >> (https://collector.torproject.org/recent/bridgestrap/) and finally check the >> latest status >> (https://collector.torproject.org/recent/bridge-descriptors/statuses/). >> >> Let me know if this helps you. I could also check the bridge myself, you >> could open an issue on gitlab under the relay-search project >> (https://gitlab.torproject.org/tpo/network-health/metrics/relay-search), or >> you can send me a private message (email or irc) with the hashed fingerprint >> and logs. >> >> Cheers, >> >> -hiro >> >> >>> >>> _______ >>> tor-relays mailing list >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DoSStreamCreation consensus parameters
According to the logs this feature is currently disabled. We will enable this protection on our exits via torrc settings. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] DoSStreamCreation consensus parameters
Hello,
today we saw yet another outbound flooding affecting our exit relays
and we were eager to see the effect of
https://gitlab.torproject.org/tpo/core/tor/-/issues/40736
but we did not see any
and according to metric
tor_relay_dos_total{type="stream_rejected"}
the protection did not trigger.
What are the consensus parameter names for these settings so we can
check there current consensus values?
DoSStreamCreationEnabled 0|1|auto
Enable the stream DoS mitigation. If set to 1 (enabled), tor will
apply rate limit on the creation of new streams and dns requests
per circuit. "auto" means use the consensus parameter. If not
defined in the consensus, the value is 0. (Default: auto)
DoSStreamCreationDefenseType NUM
This is the type of defense applied to a detected circuit or stream
for the stream mitigation. The possible values are:
1: No defense.
2: Reject the stream or resolve request.
3: Close the circuit creating too many streams.
"0" means use the consensus parameter. If not defined in the
consensus, the value is 2. (Default: 0)
DoSStreamCreationRate NUM
The allowed rate of stream creation from a single circuit per
second. Coupled with the burst (see below), if the limit is
reached, actions can be taken against the stream or circuit
(DoSStreamCreationDefenseType). If not defined or set to 0, it is
controlled by a consensus parameter. If not defined in the
consensus, the value is 100. (Default: 0)
DoSStreamCreationBurst NUM
The allowed burst of stream creation from a circuit per second. See
the DoSStreamCreationRate for more details on this detection. If
not defined or set to 0, it is controlled by a consensus parameter.
If not defined in the consensus, the value is 300. (Default: 0)
thanks!
t...@appliedprivacy.net
___________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I need a new VPS provider
Hi Landon, I can strongly recommend BuyVM.net as a good alternative. They allow all kinds of Tor nodes and have good performance + exceptional support. I've been using them for years with no issues. Seth Sent from Proton Mail Android Original Message On 22/04/2024 02:02, Landon wrote: > Hello, > > I am currently using gcore.com as my VPS hosting provider. I have been > running a Tor bridge with them for several years now. I am supposed to be > getting 200 Mbps unmetered bandwidth. However, in the past six months, my > bandwidth usage has been declining a lot. It seems like they might be > throttling my server. I was getting over 2000 connected clients and now I'm > down to less than 600. "iftop" shows me about 30 to 60 Mbps bandwidth usage > during any time of the day. Take a look... > > https://metrics.torproject.org/rs.html#details/4A0B065DB3CF807C6910DFEF6D9CCCB95C59C585 > > So, I am trying to find a Tor friendly VPS provider that offers 1 Gbps > unmetered bandwidth. I found my current provider in an article describing Tor > friendly providers, but I cannot locate that link. > > I am currently paying about 15 Euros a month for a server with 2 cores, 4 GB > RAM and 100 GB SSD. I would like to pay about the same for my new service. In > my search, I have found some better providers, but they don't seem to be Tor > friendly. > > Do you have a good provider that you really like that offers inexpensive VPS? > I would prefer one located in the USA if possible, but I guess it doesn't > matter if the bandwidth is good. > > Landon___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I need a new VPS provider
1 Gbps advertised is the NIC of the server itself. The NIC, however, is shared with other VPS accounts on the bare metal. Shared resources (even on KVM) are the definition of VPS and why they're cheaper. If you want the performance you seek, you're looking for dedicated/co-location, not a VPS. -- Original Message -- From "Landon" To tor-relays@lists.torproject.org Date 22/4/2024 4:02:21 πμ Subject [tor-relays] I need a new VPS provider Hello, I am currently using gcore.com as my VPS hosting provider. I have been running a Tor bridge with them for several years now. I am supposed to be getting 200 Mbps unmetered bandwidth. However, in the past six months, my bandwidth usage has been declining a lot. It seems like they might be throttling my server. I was getting over 2000 connected clients and now I'm down to less than 600. "iftop" shows me about 30 to 60 Mbps bandwidth usage during any time of the day. Take a look... https://metrics.torproject.org/rs.html#details/4A0B065DB3CF807C6910DFEF6D9CCCB95C59C585 So, I am trying to find a Tor friendly VPS provider that offers 1 Gbps unmetered bandwidth. I found my current provider in an article describing Tor friendly providers, but I cannot locate that link. I am currently paying about 15 Euros a month for a server with 2 cores, 4 GB RAM and 100 GB SSD. I would like to pay about the same for my new service. In my search, I have found some better providers, but they don't seem to be Tor friendly. Do you have a good provider that you really like that offers inexpensive VPS? I would prefer one located in the USA if possible, but I guess it doesn't matter if the bandwidth is good. Landon___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Webtunnel type bridge Tor Metrics
Hello everyone, I recently switched from using obfs4 to Webtunnel from my bridge. Since the configuration change, the metrics website shows it as offline. The downtime displayed on the website is also odd as it shows a random time each time I visit, such as "1 hour 14 minutes and 10 seconds" or "2 hours 23 minutes and 30 seconds." However, the bridge is online. I am wondering if this is the correct behavior for the Webtunnel protocol.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor_bug_reached_count increase
This would help us to add some more meaning to that metric again: https://gitlab.torproject.org/tpo/core/tor/-/issues/40934 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor_bug_reached_count increase
On 4/19/24 22:53, tor--- via tor-relays wrote: have a significant tor_bug_reached_count rate (around 8 per second). Here the rate is about 2-4 per hour (git-HEAD) -- Toralf ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] tor_bug_reached_count increase
Hello, the new metricsport counter shows that some specific tor relays (2 out of 50) have a significant tor_bug_reached_count rate (around 8 per second). Do you see similar? You have to run on git main or nightly builds to see that metric. best regards, t...@appliedprivacy.net ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] issues with tor-nightly-main repo
thanks a lot! best regards, t...@appliedprivacy.net ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] R: Re: R: Re: Request for Feedback on Relay Node Update Management
I have noticed that day by day the UpTime is increasing more and more (now it is up to over a day) and this is happening without me making any changes. This makes me think that somehow this is an expected thing. I do not read any errors in the log files so I consider the thread closed because apparently the problem (which is not actually a problem) has resolved itself automatically. I would love to be able to understand why it is improving but something is probably happening that only the developers could clarify for me. Thank you all for your help. Il lun, apr 15, 2024 alle 21:08, Frank Lý via tor-relays tor-relays@lists.torproject.org ha scritto: Hello Aleff, It should be okay as-is, but I would temporarily upgrade the hardware to determine if it is the root cause. Frank Apr 2, 2024, 10:34 AM by tor-relays@lists.torproject.org: My computer has: - 1 vCore CPU - 1 GB RAM - Maximum bandwidth: 1 GB/s So if I understand correctly, the problem should not be at the hardware level, right? Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays tor-relays@lists.torproject.org mailto:Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays a href= ha scritto: Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue. After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic. It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service. To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is? Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue. I will keep you updated on any progress, and I thank you once again for your support and understanding. Best regards, Aleff. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=getsearch=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays tor-relays@lists.torproject.org ha scritto: Hi Alessandro, It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability. See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your
[tor-relays] issues with tor-nightly-main repo
Hello, the repo failed to get new updates after Version: 0.4.9.0-alpha-dev-20240415T020400Z-1~d12.bookworm+1 but we would be eager to test changes that got into main in the last few days. https://deb.torproject.org/torproject.org/dists/tor-nightly-main-bookworm/main/binary-amd64/Packages aarch64 build fails. Deploy job is skipped: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/529032 https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/528021 https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/528040 best regards, applied-privacy.net ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management
Hello Aleff, It should be okay as-is, but I would temporarily upgrade the hardware to determine if it is the root cause. Frank Apr 2, 2024, 10:34 AM by tor-relays@lists.torproject.org: > My computer has: > - 1 vCore CPU > - 1 GB RAM > - Maximum bandwidth: 1 GB/s > > So if I understand correctly, the problem should not be at the hardware > level, right? > > > Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays <> > tor-relays@lists.torproject.org <mailto:Il mar, apr 2, 2024 alle 12:14, Frank > Lý via tor-relays <> > ha scritto: > >> Hello Aleff, >> >> That is up to you. I strongly suspect that the hardware is the bottleneck, >> but detailed specifications are required in order to determine a conclusion. >> Tor is currently bounded by single-thread CPU performance, with a minimum >> recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If >> your hardware does not meet these RAM requirements, upgrade it, then adjust >> the relay bandwidth rate limit as necessary. >> >> Frank >> >> Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: >> >> > I want to thank you for all the support replies you sent in response to my >> > previous communication. I have carefully read through all your insights >> > and appreciate your efforts in trying to find a solution to the issue. >> > >> > After thorough consideration of the matter, I have concluded that the >> > problem may not be due to configuration errors in the automatic updates, >> > as initially speculated. Rather, it seems that the issue could be >> > hardware-related, with my VPS computer potentially unable to handle a >> > certain amount of traffic. >> > >> > It's worth noting that there are no bandwidth issues, and the connection >> > speed is high. However, I have set a RelayBandwidthRate limit of 250 >> > Mbits. Interestingly, despite this configuration, the Tor Metrics site >> > detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 >> > Mbits. This led me to speculate that the machine might experience an >> > overload of operations or connections, causing it to crash temporarily. As >> > a result, at the time of restart, Tor Statistics records the maximum speed >> > reached up to that point (without ever reaching the set limit). >> > Subsequently, following this theory, the Tor service restarts >> > automatically without causing any anomalies in the service. >> > >> > To address this situation, I have decided to reduce the RelayBandwidthRate >> > limit from 250 Mbits to 100 Mbits, which falls within the minimum limits >> > proposed by torproject. If this is the case, however, it is also true that >> > it would be best to impose an upper limit of 80% when considering the >> > bandwidth magnitude involving the crash event as the maximum point. I >> > honestly don't know how I would be able to verify this and acquire this >> > kind of data, probably doing trial and error is the way. Perhaps the ideal >> > would be to lower the maximum bandwidth further to verify for sure that >> > this is what it is? >> > >> > Currently, I am closely monitoring the situation to assess whether this >> > modification has a positive impact on the issue. >> > >> > I will keep you updated on any progress, and I thank you once again for >> > your support and understanding. >> > >> > Best regards, >> > >> > Aleff. >> > >> > --- >> > >> > Browse my WebSite: aleff-gitlab.gitlab.io >> > Use my PGP Public Key: >> > pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 >> > Join to support: >> > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) >> > - Electronic Frontier Foundation! (eff.org) >> > - Tor-Project (torproject.org) >> > - Signal (signal.org) >> > >> > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays >> > ha scritto: >> > >> >> Hi Alessandro, >> >> >> >> It's good to hear from you. I have a relay in a somewhat similar >> >> situation[1], although I've only just clocked it. If you're using Debian >> >> or one of its derivatives, then you can configure the unattended-upgrades >> >> package to perform a restart at a specific time if required. This means >> >> that your relay won't restart every time an upgrade is required, but will >> >> keep itself up t
Re: [tor-relays] disable conflux on exit relay?
This tor is a relay and ConfluxEnabled is set to 0. We would ask you to please write to us on tor-re...@lists.torproject.org there is a typo in the code that generates that log line: tor-relay@ should be tor-relays@ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] disable conflux on exit relay?
will ConfluxEnabled 0 disable it for tor acting as a client only or for relays as well? Yes, it affects relays as well, not just clients. Due to the high frequency of bug events related to conflux, especially: https://gitlab.torproject.org/tpo/core/tor/-/issues/40908 the tor_bug_reached metric basically becomes meaningless because it is "normal" to see that counter increase all the time. To work around that issue we filed the following issue which would make it possible to run exits with conflux enabled without rendering the tor_bug_reached metric meaningless: https://gitlab.torproject.org/tpo/core/tor/-/issues/40930 FYI from the tor log file: This tor is a relay and ConfluxEnabled is set to 0. We would ask you to please write to us on tor-re...@lists.torproject.org or file a bug explaining why you have disabled this option. Without news from you, we might end up marking your relay as a BadExit. _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] disable conflux on exit relay?
Hello, conflux appears to be the primary source of bugs and crashes for us in the past few months and there have been numerous issues related to it on gitlab. from the tor manual page: ConfluxEnabled 0|1|auto If this option is set to 1, general purpose traffic will use Conflux which is traffic splitting among multiple legs (circuits). Onion services are not supported at the moment. Default value is set to "auto" meaning the consensus is used to decide unless set. (Default: auto) will ConfluxEnabled 0 disable it for tor acting as a client only or for relays as well? thanks! applied-privacy.net _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management
I made the changes you recommended and also added/edited these parameters in the torrc configuration file: - RunAsDaemon 1 - RelayBandwidthRate 10 MB - RelayBandwidthBurst 20 MB But in spite of that I did not solve the problem. I monitored via nyx what was happening on service reboot and noticed that it detects the tor control port closed. Regarding this setting in the torrc file I wrote. - ControlPort 9051 - CookieAuthentication 1 And trying to run nmap to see if port 9051 is open it shows me open in LISTENING mode. To make what I tried to report in this email clearer I have uploaded a 15-second video[1] that captures the exact moment when the shutdown occurs where you can see that at first port 9051 is working properly while at some point it seems to shut down automatically. It's possible that the Tor service never ceases to function, but for some strange reason, the port 9051 stops functioning, preventing the control of Tor itself. As a result, it may appear that Tor has restarted, when in fact the uptime simply resets because the port 9051 is unreachable for a certain period of time. [1] https://vimeo.com/930658793 martedì 2 aprile 2024 23:24, denny.obre...@a-n-o-n-y-m-e.net ha scritto: > You should tweak your web server as presented in this section: > > > > https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-preparing-your-system-for-high-number-of-connections > > > > This would most likely solve Out-Of-Memory problems I suspect you are > experiencing. > > > > Denny > > > On 04/02/2024 10:06 AM Alessandro Greco via tor-relays wrote .. > > > My computer has: > > - 1 vCore CPU > > - 1 GB RAM > > - Maximum bandwidth: 1 GB/s > > > > So if I understand correctly, the problem should not be at the hardware > > level, right? > > > > > > Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays > > ha scritto: > > > > > Hello Aleff, > > > > > > That is up to you. I strongly suspect that the hardware is the > > > bottleneck, but detailed specifications are required in order to > > > determine a conclusion. Tor is currently bounded by single-thread CPU > > > performance, with a minimum recommendation of 1 GB of RAM for non-exit > > > relays faster than 40 Mbit/s. If your hardware does not meet these RAM > > > requirements, upgrade it, then adjust the relay bandwidth rate limit as > > > necessary. > > > > > > Frank > > > > > > Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: > > > > > > > I want to thank you for all the support replies you sent in response to > > > > my previous communication. I have carefully read through all your > > > > insights and appreciate your efforts in trying to find a solution to > > > > the issue. > > > > > > > > After thorough consideration of the matter, I have concluded that the > > > > problem may not be due to configuration errors in the automatic > > > > updates, as initially speculated. Rather, it seems that the issue could > > > > be hardware-related, with my VPS computer potentially unable to handle > > > > a certain amount of traffic. > > > > > > > > It's worth noting that there are no bandwidth issues, and the > > > > connection speed is high. However, I have set a RelayBandwidthRate > > > > limit of 250 Mbits. Interestingly, despite this configuration, the Tor > > > > Metrics site detects a spee d of approximately 10/13 MBytes, equivalent > > > > to about 90/110 Mbits. This led me to speculate that the machine might > > > > experience an overload of operations or connections, causing it to > > > > crash temporarily. As a result, at the time of restart, Tor Statistics > > > > records the maximum speed reached up to that point (without ever > > > > reaching the set limit). Subsequently, following this theory, the Tor > > > > service restarts automatically without causing any anomalies in the > > > > service. > > > > > > > > To address this situation, I have decided to reduce the > > > > RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls > > > > within the minimum limits proposed by torproject. If this is the case, > > > > however, it is also true that it would be best to impose an upper limit > > > > of 80% when considering the bandwidth magnitude involving the crash > > > > event as the maximum point. I honestly don't know how I would be able > &
Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management
Hello, My computer has:- 1 vCore CPU- 1 GB RAM- Maximum bandwidth: 1 GB/sSo if I understand correctly, the problem should not be at the hardware level, right?For running a relay, I definitely recommend you upgrade to at least 2gb of Ram per vCore or 2GB per 1 Tor instance. On my fleet of relays the minimum spec I use is 2vCores and 4GB ram. John - prsv admin signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] R: Re: Request for Feedback on Relay Node Update Management
My computer has:- 1 vCore CPU- 1 GB RAM- Maximum bandwidth: 1 GB/s So if I understand correctly, the problem should not be at the hardware level, right? Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays tor-relays@lists.torproject.org ha scritto: Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue. After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic. It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service. To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is? Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue. I will keep you updated on any progress, and I thank you once again for your support and understanding. Best regards, Aleff. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=getsearch=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays tor-relays@lists.torproject.org ha scritto: Hi Alessandro, It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability. See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your relay is restarting. I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not required and that restarts to the daemon or node are fine. Because of this, it might not be worth worrying too much about this issue. I hope you find some of this useful, Seth [1] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE [2] https://community.torproject.org/relay/relays-requirements/ Original Message On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@lists.torproject.org wrote: Dear Tor-Relays Mailing List Members, I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B
Re: [tor-relays] User advisory to check for xz-utils backdoor
On Freitag, 29. März 2024 19:39:05 CEST pasture_clubbed242--- via tor-relays wrote: > > The near-universally used 'xz' compression library has been found to contain > a backdoor in certain code branches. This backdoor has made it into some > systems such as Debian Sid. > > Details regarding this backdoor are available here. > https://www.openwall.com/lists/oss-security/2024/03/29/4 Pretty unlikely that anyone uses testing or sid for productive servers. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] User advisory to check for xz-utils backdoor
Greetings, I do not normally use mailing lists such as this one to inform subscribers of security notices, but this issue is extreme enough where it may benefit the anonymity of Tor users if relay operators are aware of it sooner. The near-universally used 'xz' compression library has been found to contain a backdoor in certain code branches. This backdoor has made it into some systems such as Debian Sid. Details regarding this backdoor are available here. https://www.openwall.com/lists/oss-security/2024/03/29/4 It is suspected that if your OpenSSH server links to the xz library, which Debian appears to do so, then this backdoor is remotely exploitable. If your OpenSSH server does not link to this library, then your system still contains many processes that run xz actions as the root user, some input of which may be less than trusted. For those needing a patch, I recommend you research your distribution's security advisory page for further information. References: Debian Sid Advisory: https://security-tracker.debian.org/tracker/CVE-2024-3094 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Backdoor in upstream xz/liblzma leading to ssh server compromise
Just wanted to bring this to everyone’s attention if you hadn’t seen it already. Developer discovered a backdoor in xz-utils https://www.openwall.com/lists/oss-security/2024/03/29/4 -- Sent from Canary (https://canarymail.io) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Request for Feedback on Relay Node Update Management
Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: > I want to thank you for all the support replies you sent in response to my > previous communication. I have carefully read through all your insights and > appreciate your efforts in trying to find a solution to the issue. > > After thorough consideration of the matter, I have concluded that the problem > may not be due to configuration errors in the automatic updates, as initially > speculated. Rather, it seems that the issue could be hardware-related, with > my VPS computer potentially unable to handle a certain amount of traffic. > > It's worth noting that there are no bandwidth issues, and the connection > speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. > Interestingly, despite this configuration, the Tor Metrics site detects a > speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This > led me to speculate that the machine might experience an overload of > operations or connections, causing it to crash temporarily. As a result, at > the time of restart, Tor Statistics records the maximum speed reached up to > that point (without ever reaching the set limit). Subsequently, following > this theory, the Tor service restarts automatically without causing any > anomalies in the service. > > To address this situation, I have decided to reduce the RelayBandwidthRate > limit from 250 Mbits to 100 Mbits, which falls within the minimum limits > proposed by torproject. If this is the case, however, it is also true that it > would be best to impose an upper limit of 80% when considering the bandwidth > magnitude involving the crash event as the maximum point. I honestly don't > know how I would be able to verify this and acquire this kind of data, > probably doing trial and error is the way. Perhaps the ideal would be to > lower the maximum bandwidth further to verify for sure that this is what it > is? > > Currently, I am closely monitoring the situation to assess whether this > modification has a positive impact on the issue. > > I will keep you updated on any progress, and I thank you once again for your > support and understanding. > > Best regards, > > Aleff. > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org) > > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays > ha scritto: > >> Hi Alessandro, >> >> It's good to hear from you. I have a relay in a somewhat similar >> situation[1], although I've only just clocked it. If you're using Debian or >> one of its derivatives, then you can configure the unattended-upgrades >> package to perform a restart at a specific time if required. This means that >> your relay won't restart every time an upgrade is required, but will keep >> itself up to date. I think configuring a time for a daily restart (if >> upgrade required) would be a fairly good balance between stability and >> reliability. >> >> See what other people say or from your own experience, as Tor circuits are >> generally quite resilient and as long as you aren't a guard node I believe >> connections won't die because your relay is restarting. >> >> I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not >> required and that restarts to the daemon or node are fine. Because of this, >> it might not be worth worrying too much about this issue. >> >> I hope you find some of this useful, >> Seth >> >> >> >> [1] >> https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE >> [2] https://community.torproject.org/relay/relays-requirements/ >> Original Message >> On 26/03/2024 08:54, Alessandro Greco via tor-relays >> tor-relays@lists.torproject.org wrote: >> >> > Dear Tor-Relays Mailing List Members, >> > >> >> > I hope this email finds you well. I'm reaching out to share some >> > observations and pose some que
Re: [tor-relays] Request for Feedback on Relay Node Update Management
No dice, this solution did not solve the problem for me either. My VPS holds up well to a maximum traffic of this magnitude and the hardware resources are not used more than 50% but nevertheless it keeps shutting down and restarting the tor service up to a maximum Uptime of 3 hours (but often restarts earlier). I want to specify that it does not restart the VPS but only the tor service. I also do not detect any files in the path "/var/log/tor". I would not know what else to check. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) mercoledì 27 marzo 2024 14:55, Alessandro Greco via tor-relays ha scritto: > I want to thank you for all the support replies you sent in response to my > previous communication. I have carefully read through all your insights and > appreciate your efforts in trying to find a solution to the issue. > > After thorough consideration of the matter, I have concluded that the problem > may not be due to configuration errors in the automatic updates, as initially > speculated. Rather, it seems that the issue could be hardware-related, with > my VPS computer potentially unable to handle a certain amount of traffic. > > It's worth noting that there are no bandwidth issues, and the connection > speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. > Interestingly, despite this configuration, the Tor Metrics site detects a > speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This > led me to speculate that the machine might experience an overload of > operations or connections, causing it to crash temporarily. As a result, at > the time of restart, Tor Statistics records the maximum speed reached up to > that point (without ever reaching the set limit). Subsequently, following > this theory, the Tor service restarts automatically without causing any > anomalies in the service. > > To address this situation, I have decided to reduce the RelayBandwidthRate > limit from 250 Mbits to 100 Mbits, which falls within the minimum limits > proposed by torproject. If this is the case, however, it is also true that it > would be best to impose an upper limit of 80% when considering the bandwidth > magnitude involving the crash event as the maximum point. I honestly don't > know how I would be able to verify this and acquire this kind of data, > probably doing trial and error is the way. Perhaps the ideal would be to > lower the maximum bandwidth further to verify for sure that this is what it > is? > > Currently, I am closely monitoring the situation to assess whether this > modification has a positive impact on the issue. > > I will keep you updated on any progress, and I thank you once again for your > support and understanding. > > Best regards, > > Aleff. > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org) > > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays > tor-relays@lists.torproject.org ha scritto: > > > Hi Alessandro, > > > It's good to hear from you. I have a relay in a somewhat similar > > situation[1], although I've only just clocked it. If you're using Debian or > > one of its derivatives, then you can configure the unattended-upgrades > > package to perform a restart at a specific time if required. This means > > that your relay won't restart every time an upgrade is required, but will > > keep itself up to date. I think configuring a time for a daily restart (if > > upgrade required) would be a fairly good balance between stability and > > reliability. > > > See what other people say or from your own experience, as Tor circuits are > > generally quite resilient and as long as you aren't a guard node I believe > > connections won't die because your relay is restarting. > > > I would also note that Tor recommends [2] an uptime or 24/7 is nice, but > > not required and that restarts to the daemon or node are fine. Because of > > this, it might not be worth worrying too much about this issue. > > > I hope you find some of this useful, > > Seth > > > [1] > > https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE > > [2] http
Re: [tor-relays] Request for Feedback on Relay Node Update Management
I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue. After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic. It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service. To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is? Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue. I will keep you updated on any progress, and I thank you once again for your support and understanding. Best regards, Aleff. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays ha scritto: > Hi Alessandro, > > It's good to hear from you. I have a relay in a somewhat similar > situation[1], although I've only just clocked it. If you're using Debian or > one of its derivatives, then you can configure the unattended-upgrades > package to perform a restart at a specific time if required. This means that > your relay won't restart every time an upgrade is required, but will keep > itself up to date. I think configuring a time for a daily restart (if upgrade > required) would be a fairly good balance between stability and reliability. > > See what other people say or from your own experience, as Tor circuits are > generally quite resilient and as long as you aren't a guard node I believe > connections won't die because your relay is restarting. > > I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not > required and that restarts to the daemon or node are fine. Because of this, > it might not be worth worrying too much about this issue. > > I hope you find some of this useful, > Seth > > > [1] > https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE > [2] https://community.torproject.org/relay/relays-requirements/ > ---- Original Message > On 26/03/2024 08:54, Alessandro Greco via tor-relays > tor-relays@lists.torproject.org wrote: > > > Dear Tor-Relays Mailing List Members, > > > > I hope this email finds you well. I'm reaching out to share some > > observations and pose some questions regarding the management of relay node > > updates, particularly concerning their impact on stability and security of > > the service provided. > > > > Recently, I've noticed an interesting pattern with my relay node (ID: > > 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's > > recommendations [2] and configured automatic updates, which has led to > > frequent restarts of the node to keep the Tor software up-to-date. While > > this practice ensures high security by keeping the software updated, it > > seems to compromise the stability of the node itself. The Uptime value of > > my node has remained at a maximum of a few hours. > > > > This situation has prompted me to reflect on what might be the best > > strategy to adopt. On one hand, frequent updates ensure optimal se
Re: [tor-relays] Request for Feedback on Relay Node Update Management
Hello Aleff, Yes. No. No. I used Debian, so updates were less frequent, maybe once every 3-5 weeks or so. Frank Mar 26, 2024, 3:03 AM by tor-relays@lists.torproject.org: > Dear Tor-Relays Mailing List Members, > > I hope this email finds you well. I'm reaching out to share some observations > and pose some questions regarding the management of relay node updates, > particularly concerning their impact on stability and security of the service > provided. > > Recently, I've noticed an interesting pattern with my relay node (ID: > 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's > recommendations [2] and configured automatic updates, which has led to > frequent restarts of the node to keep the Tor software up-to-date. While this > practice ensures high security by keeping the software updated, it seems to > compromise the stability of the node itself. The Uptime value of my node has > remained at a maximum of a few hours. > > This situation has prompted me to reflect on what might be the best strategy > to adopt. On one hand, frequent updates ensure optimal security, while on the > other hand, continuous restarts may affect the user experience for those > relying on the node's stability for their Tor activities. > > As such, I'd like to pose some questions to the community to gather feedback > and assess best practices: > > 1. In your opinion, is it preferable to maintain automatic updates to ensure > maximum security, even if frequent restarts may compromise the node's > stability? > 2. Or would it be more sensible to adjust the update frequency, perhaps > performing them once or twice a week, to ensure greater stability of the node > without excessively compromising security? > 3. Have you had similar experiences with your relay nodes? How have you > addressed this challenge and what were the outcomes? > > Thank you in advance for your time and cooperation. > > Best regards, > Aleff. > > [1] > https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E3BE81E63056B > [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/ > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org) > _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Request for Feedback on Relay Node Update Management
Hi Alessandro, It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability. See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your relay is restarting. I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not required and that restarts to the daemon or node are fine. Because of this, it might not be worth worrying too much about this issue. I hope you find some of this useful, Seth [1] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE [2] https://community.torproject.org/relay/relays-requirements/ Original Message On 26/03/2024 08:54, Alessandro Greco via tor-relays wrote: > Dear Tor-Relays Mailing List Members, > > I hope this email finds you well. I'm reaching out to share some > observations and pose some questions regarding the management of relay node > updates, particularly concerning their impact on stability and security of > the service provided. > > Recently, I've noticed an interesting pattern with my relay node (ID: > 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's > recommendations [2] and configured automatic updates, which has led to > frequent restarts of the node to keep the Tor software up-to-date. While this > practice ensures high security by keeping the software updated, it seems to > compromise the stability of the node itself. The Uptime value of my node has > remained at a maximum of a few hours. > > This situation has prompted me to reflect on what might be the best strategy > to adopt. On one hand, frequent updates ensure optimal security, while on the > other hand, continuous restarts may affect the user experience for those > relying on the node's stability for their Tor activities. > > As such, I'd like to pose some questions to the community to gather feedback > and assess best practices: > > 1. In your opinion, is it preferable to maintain automatic updates to ensure > maximum security, even if frequent restarts may compromise the node's > stability? > 2. Or would it be more sensible to adjust the update frequency, perhaps > performing them once or twice a week, to ensure greater stability of the node > without excessively compromising security? > 3. Have you had similar experiences with your relay nodes? How have you > addressed this challenge and what were the outcomes? > > Thank you in advance for your time and cooperation. > > Best regards, > Aleff. > > [1] > https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E3BE81E63056B > [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/ > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: > pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org)_______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Request for Feedback on Relay Node Update Management
On 3/26/24 09:54, Alessandro Greco via tor-relays wrote: Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. I do run a bunch of Tor (bridges), all at Debian bookworm. I enabled automatic unattended updates for all packages (not the so-alled "security" ones). I did not observed any frequently restarts. My configs are in [1] and [2]. [1] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/templates/upgrade.j2 [2] https://github.com/toralf/tor-relays/tree/main/playbooks/roles/setup/files -- Toralf _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Request for Feedback on Relay Node Update Management
Hi Allessandro, My two cents: I deliberately don't use automatic updates to improve relay stability and only update when it's necessary. And this applies to any updates including the FreeBSD/OpenBSD kernel (which requires a reboot as well). Not all updates are security patches or are relevant enough to immediately effectuate. Sometimes they can go ~60 days without needing a Tor restart. But your mileage may vary. For example some operators compile Tor daily and then a restart may be required more often. I do feel something is wrong in your configuration though. Tor certainly has updates occasionally, but not every few hours. Also in Tor Project's Debian repo[1] it looks like the last update was from 22-03 (and not a few hours ago). So you may want to check your apt configuration. I don't use Debian/Linux so someone else could maybe chime in to help you with setting that up properly. Regards, tornth [1] https://deb.torproject.org/torproject.org/dists/ Mar 26, 2024, 11:03 by tor-relays@lists.torproject.org: > Dear Tor-Relays Mailing List Members, > > I hope this email finds you well. I'm reaching out to share some observations > and pose some questions regarding the management of relay node updates, > particularly concerning their impact on stability and security of the service > provided. > > Recently, I've noticed an interesting pattern with my relay node (ID: > 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's > recommendations [2] and configured automatic updates, which has led to > frequent restarts of the node to keep the Tor software up-to-date. While this > practice ensures high security by keeping the software updated, it seems to > compromise the stability of the node itself. The Uptime value of my node has > remained at a maximum of a few hours. > > This situation has prompted me to reflect on what might be the best strategy > to adopt. On one hand, frequent updates ensure optimal security, while on the > other hand, continuous restarts may affect the user experience for those > relying on the node's stability for their Tor activities. > > As such, I'd like to pose some questions to the community to gather feedback > and assess best practices: > > 1. In your opinion, is it preferable to maintain automatic updates to ensure > maximum security, even if frequent restarts may compromise the node's > stability? > 2. Or would it be more sensible to adjust the update frequency, perhaps > performing them once or twice a week, to ensure greater stability of the node > without excessively compromising security? > 3. Have you had similar experiences with your relay nodes? How have you > addressed this challenge and what were the outcomes? > > Thank you in advance for your time and cooperation. > > Best regards, > Aleff. > > [1] > https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E3BE81E63056B > [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/ > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org) > _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Request for Feedback on Relay Node Update Management
Dear Tor-Relays Mailing List Members, I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours. This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities. As such, I'd like to pose some questions to the community to gather feedback and assess best practices: 1. In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability? 2. Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security? 3. Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes? Thank you in advance for your time and cooperation. Best regards, Aleff. [1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E3BE81E63056B [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/ --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) publickey - alessandro.greco.1@protonmail.com - 0x1D14CC10.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] GeoIPFile option warning
krishna e bera wrote: I am seeing these warnings in Tor's notices.log: Mar 24 09:42:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Mar 24 09:42:21.000 [notice] Configured to measure entry node statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. However the option is set in torrc and i verified the files are at those locations and readable by all: GeoIPFile /usr/local/share/tor/geoip GeoIPv6File /usr/local/share/tor/geoip6 Any hints how i could check whether the warnings are spurious or dump what the running config actually is? I know it is reading the torrc because introducing an error in the file stops it from loading. Do you get such notices: Mar 25 12:43:29.000 [notice] Parsing GEOIP IPv4 file f:\Mingw32\src\inet\Tor-Project\src\config\geoip. Mar 25 12:43:29.000 [notice] Parsing GEOIP IPv6 file f:\Mingw32\src\inet\Tor-Project\src\config\geoip6. in your .log-files? If not, 'tor_fopen_cloexec()' fails to read them. I'm on Windows (as you see) and thus have no issue with this 'FD_CLOEXEC' non-sense that your may have. Or try running 'scripts/maint/geoip/update_geoip.sh'. -- --gv ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor is not upgrading via apt from deb.torproject.org
On 2/15/24 17:16, li...@for-privacy.net wrote:
I let nightly's upgrade automatically, but not stable.
Therefore I have the following config in
/etc/apt/50unattended-upgrades
Unattended-Upgrade::Origins-Pattern {
...
// Update TorProject's nightly dev packages: (Suite & Codename:
tor-nightly-main-bookworm)
// apt-cache policy | grep release
"o=TorProject,a=tor-nightly-main-bookworm,n=tor-nightly-main-bookworm";
};
I do have (in [1])
Unattended-Upgrade::Origins-Pattern {
"origin=*";
};
Unattended-Upgrade::Package-Blacklist {
};
Unattended-Upgrade::Automatic-Reboot "true";
which seems to work fine - it upgrades every package from every
repo/release if needed.
[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/files/50unattended-upgrades
--
Toralf
___________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node 6E02FDEA15122A492A799A58C4C11D02637B145A is marked as down, but logs display no issues
Hi Roman, On 14/03/2024 13:20, Roman Mamedov wrote: > > The reason is that your IPv6 2a05:541:112:31::1 is not accessible. > Did you check port 9001 on IPv6 from the outside? > Thank you, I did not check indeed. Something has probably changed on the provider side, since no configuration has been changed in the recent weeks, and weirdly enough the server can still exit in ipv6, but does not answer to pings from outside. I have temporarily disabled IPv6Exit and the respective listening ports while we investigate. Cheers Giulio ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Node 6E02FDEA15122A492A799A58C4C11D02637B145A is marked as down, but logs display no issues
Hi all, our node sacco.osservatorionessuno.org[1] has been marked down for more than a couple of days. It is at the latest version from Tor's Debian repository and I tried to restart both the service and the server. The process is running, and the 9001 and 9030 ports are open and succesfully reachable from the outside. The notice log I temporarily enabled to look for the issue apparently does not show any warning signs. Here is an anonymized output of the log: [notice] Tor 0.4.8.10 opening new log file. [notice] We compiled with OpenSSL XXX and we are running with OpenSSL XXX. These two versions should be binary compatible. [notice] Tor 0.4.8.10 running on Linux with Libevent XXX, OpenSSL XXX, Zlib XXX, Liblzma XXX, Libzstd XXX and Glibc XXX as libc. [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ [notice] Read configuration file "/etc/tor/torrc". [notice] Based on detected system memory, MaxMemInQueues is set to 720 MB. You can override this by setting MaxMemInQueues by hand. [notice] Opening Socks listener on 127.0.0.1:9050 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050 [notice] Opening OR listener on XXX:9001 [notice] Opened OR listener connection (ready) on XXX:9001 [notice] Opening OR listener on [XXX]:9001 [notice] Opened OR listener connection (ready) on [XXX]:9001 [notice] Opening Directory listener on XXX:9030 [notice] Opened Directory listener connection (ready) on XXX:9030 [notice] Opening Directory listener on [XXX]:9030 [notice] Opened Directory listener connection (ready) on [XXX]:9030 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. [notice] Your Tor server's identity key fingerprint is 'sacco XXX' [notice] Your Tor server's identity key ed25519 fingerprint is 'sacco XXX' [notice] Bootstrapped 0% (starting): Starting [notice] Starting with guard context "default" [notice] Bootstrapped 5% (conn): Connecting to a relay [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address. [notice] Bootstrapped 10% (conn_done): Connected to a relay [notice] Bootstrapped 14% (handshake): Handshaking with a relay [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit [notice] External address seen and suggested by a directory authority: XXX [notice] Bootstrapped 100% (done): Done [notice] Now checking whether IPv4 ORPort XXX:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) [notice] Now checking whether IPv6 ORPort [XXX]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) [notice] Self-testing indicates your ORPort XXX:9001 is reachable from the outside. Excellent. [notice] Performing bandwidth self-test...done. [notice] Self-testing indicates your ORPort [XXX]:9001 is reachable from the outside. Excellent. Publishing server descriptor. [notice] Heartbeat: It seems like we are not in the cached consensus. [notice] Heartbeat: Tor's uptime is XX hours, with XX circuits open. I've sent XX and received XX. I've received XXX connections on IPv4 and XXX on IPv6. I've made XXX connections with IPv4 and XXX with IPv6. [notice] While bootstrapping, fetched this many bytes: XXX (microdescriptor fetch) [notice] While not bootstrapping, fetched this many bytes: XXX (server descriptor fetch); XXX (server descriptor upload); XXX (consensus network-status fetch); XXX (microdescriptor fetch) [notice] Circuit handshake stats since last time: X/X TAP, X/X NTor. [notice] Since startup we initiated XXX and received XXX v1 connections; initiated 0 and received 0 v2 connections; initiated XXX and received XXX v3 connections; initiated XXX and received XXX v4 connections; initiated XXX and received XXX v5 connections. [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. [notice] Your network connection speed appears to have changed. Resetting timeout to XXXms after XXX timeouts and XXX buildtimes. We would appreciate any hint on how to proceed to debug the issue in order to keep the server useful. Thank you Giuio [1] - https://metrics.torproject.org/rs.html#details/6E02FDEA15122A492A79
Re: [tor-relays] bridges for Lox
>> On 27 Feb 2024, at 15:39, boldsuck wrote: >> On Dienstag, 27. Februar 2024 14:52:00 CET Corl3ss via tor-relays wrote: >>> On 26/02/2024 21:03, Toralf Förster via tor-relays wrote: >>>> On 2/26/24 20:07, meskio wrote: >>>>> At the moment we're >>>>> looking for 10 new bridges for Lox. If it has to be done quickly, I can also deploy the other 4. >>>> 9 left >>> >>> And one more added, so 8 left. >> +1 = 7 left > > Added one. 6 left. 4 left. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bridges for Lox
> On 27 Feb 2024, at 15:39, boldsuck wrote: > On Dienstag, 27. Februar 2024 14:52:00 CET Corl3ss via tor-relays wrote: >> On 26/02/2024 21:03, Toralf Förster via tor-relays wrote: >>> On 2/26/24 20:07, meskio wrote: >>>> At the moment we're >>>> looking for 10 new bridges for Lox. >>> 9 left >> >> And one more added, so 8 left. > +1 = 7 left Added one. 6 left. _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bridges for Lox
On 2/27/24 21:14, boldsuck wrote: Gentoo & FreeBSD-Port Dev's and users are years ahead ;-) Whilst I'd agree on that my Tor bridges and Snowflakes do run under a recent Debian. However Tor et al are compiled from sources. [1] [2] [1] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-tor/tasks/tor-git.yaml [2] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-tor/tasks/lyrebird.yaml -- Toralf ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-relays Digest, Vol 157, Issue 19
+1 incoming. On Tuesday, February 27th, 2024 at 04:17, tor-relays-requ...@lists.torproject.org wrote: > > > Send tor-relays mailing list submissions to > tor-relays@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-requ...@lists.torproject.org > > You can reach the person managing the list at > tor-relays-ow...@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. bridges for Lox (meskio) > 2. Re: bridges for Lox (Toralf F?rster) > 3. Re: bridges for Lox (Toralf F?rster) > 4. Re: bridges for Lox (meskio) > > > -- > > Message: 1 > Date: Mon, 26 Feb 2024 20:07:45 +0100 > From: meskio mes...@torproject.org > > To: tor-relays tor-relays@lists.torproject.org > > Subject: [tor-relays] bridges for Lox > Message-ID: 170897446522.1760.2953283832616396350@localhost > > Content-Type: text/plain; charset="utf-8" > > Hello, > > We are developing a reputation based bridge distributor called Lox[0] and are > preparing to make a call for users to test it in Tor Browser Alpha. In order > to > do this, we need to have some new bridges that can be distributed by Lox. Do > you > want to give us a hand running a bridge (or few) for Lox? At the moment we're > looking for 10 new bridges for Lox. > > Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now, > but will instead accept bridges with the 'BridgeDistribution lox' configured > in > torrc. > > To set up a bridge for Lox, configure a normal obfs4 bridge[1] and simply > include the following line in torrc: > BridgeDistribution lox > > As Lox is only going to be released for testing, you might not see a lot of > traffic on Lox bridges at the moment. However, these bridges will be very > useful > for us to improve Lox and see what works and what does not. > > Thank you > > > [0] https://gitlab.torproject.org/tpo/anti-censorship/lox > [1] https://community.torproject.org/relay/setup/bridge/ > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan. > -- next part -- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: signature > URL: > http://lists.torproject.org/pipermail/tor-relays/attachments/20240226/658c1e8e/attachment-0001.sig > > > -- > > Message: 2 > Date: Mon, 26 Feb 2024 21:03:13 +0100 > From: Toralf F?rster toralf.foers...@gmx.de > > To: tor-relays@lists.torproject.org > Subject: Re: [tor-relays] bridges for Lox > Message-ID: 7ea7df6d-36a3-463b-be55-0e1c72179...@gmx.de > > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 2/26/24 20:07, meskio wrote: > > > At the moment we're > > looking for 10 new bridges for Lox. > > > 9 left > > -- > Toralf > > > > -- > > Message: 3 > Date: Mon, 26 Feb 2024 21:07:50 +0100 > From: Toralf F?rster toralf.foers...@gmx.de > > To: tor-relays@lists.torproject.org > Subject: Re: [tor-relays] bridges for Lox > Message-ID: e92d9716-99d0-43ca-8959-0727aa1d3...@gmx.de > > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 2/26/24 20:07, meskio wrote: > > > Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for > > now, > > but will instead accept bridges with the 'BridgeDistribution lox' > > configured in > > torrc. > > > BTW by accident I configured "any" but restarted tor with "lox" 2 > minutes later. Does that work? > > And FWIW: > > root@luchs:~# grep lox /var/log/tor/notice.log > Feb 26 20:03:50.008 [warn] Unrecognized BridgeDistribution value "lox". > I'll assume you know what you are doing... > > root@luchs:~# tor --version > Tor version 0.4.9.0-alpha-dev (git-b0b943a1613e2f9b). > Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, > Zlib 1.2.13, Liblzma N/A, Libzstd N/A and Glibc 2.36 as libc. > Tor compiled with GCC version 12.2.0 > > -- > Toralf > > > > -- > > Message: 4 > Date: T
Re: [tor-relays] bridges for Lox
On 2/27/24 16:38, boldsuck wrote: ORPort 127.0.0.1:14255 ORPort [::1]:14255 I do not specified the ipv6 port explicietly: SandBox 0 ORPort 127.0.0.1:auto AssumeReachable 1 ExtORPort auto ServerTransportPlugin obfs4 exec /usr/bin/lyrebird Would it be needed? -- Toralf ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bridges for Lox
On 26/02/2024 21:03, Toralf Förster via tor-relays wrote: On 2/26/24 20:07, meskio wrote: At the moment we're looking for 10 new bridges for Lox. 9 left And one more added, so 8 left. Meskio, Feel free to reach me directly if further information needed. Corl3ss ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bridges for Lox
On 2/26/24 20:07, meskio wrote: Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now, but will instead accept bridges with the 'BridgeDistribution lox' configured in torrc. BTW by accident I configured "any" but restarted tor with "lox" 2 minutes later. Does that work? And FWIW: root@luchs:~# grep lox /var/log/tor/notice.log Feb 26 20:03:50.008 [warn] Unrecognized BridgeDistribution value "lox". I'll assume you know what you are doing... root@luchs:~# tor --version Tor version 0.4.9.0-alpha-dev (git-b0b943a1613e2f9b). Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma N/A, Libzstd N/A and Glibc 2.36 as libc. Tor compiled with GCC version 12.2.0 -- Toralf ___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bridges for Lox
On 2/26/24 20:07, meskio wrote: At the moment we're looking for 10 new bridges for Lox. 9 left -- Toralf ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relay Automatic PMTU Testing
Usually lower MTUs are not a problem for properly configured networks, as even lower MTU systems should begin fragmenting traffic. The issue comes where there is a mismatch, and suddenly, larger than expected packets are dropped. So I think the tor protocol does not need to support identifying relay MTUs, but I'm also unsure if it tests the largest cell size against relays either. Testing a very large cell size should identify if a relay is properly configured. Original Message On Feb 22, 2024, 5:47 AM, s7r - s7r at sky-ip.org wrote: > pasture_clubbed242--- via tor-relays wrote: > Greetings, > > I believe there > is a larger sized guard relay that has been having MTU > issues for about a > week. All connections with packets above a certain > size are dropped. This > results in partially loaded or broken webpages, > broken file downloads, etc. > Do Tor directory authorities test MTU > (implicitly by speed test?) when > testing relays? > > Wondering if anyone else noticed this or if it would be > handled > automatically by dir authorities. > > Thanks all > This is indeed > very interesting. I never experienced this problem but now that you mention > it I will setup a test environment with some non standard MTU values. I doubt > the directory authorities test also the MTU, but it's an interesting > question, let's hope someone hosting a bandwidth authority will reply to > this. Also, I'm not sure and I'm very curios what the bandwidth authorities > should do about this? What if a relay has super good speed but very low MTU? > Should it be excluded and marked as not running? Because it will be very hard > for Tor to also include MTU in the router descriptors and be aware about it. > ___ tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor Relay Automatic PMTU Testing
Greetings, I believe there is a larger sized guard relay that has been having MTU issues for about a week. All connections with packets above a certain size are dropped. This results in partially loaded or broken webpages, broken file downloads, etc. Do Tor directory authorities test MTU (implicitly by speed test?) when testing relays? Wondering if anyone else noticed this or if it would be handled automatically by dir authorities. Thanks all___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] VPS w/FDE suggestions?
Hello- Im looking for <= $6/mo VPS suggestions for general non-tor server and also for tor. Some super-cheap hosts pre-install O/S and give root but I want to install O/S myself so can put in FDE. Hard to see which hosts can do this. I tried Linode before and yes, could get FDE ($5 1GB, 1CPU, 25GB, 1TB) Is IONOS any good? Can I get FDE there?? ($2 1GB, 1CPU, 10GB, ?TB) ($3 2GB, 2CPU, 80GB, ?TB) ($6 4GB, 2CPU, 160GB, ?TB) Others caught my eye: hudsonvalleyhost ($3.95 1GB, 1CPU, 25GB, 20TB) ($6.95 2GB, 2CPU, 50GB, 20TB) liquidweb ($5 1GB, 1CPU, 30GB, 1TB) digitalocean ($6 1GB, 1CPU, 25GB, 20TB) ovhcloud ($4.20 2GB, 1CPU, 20GB, 100Mbps unmetered) ($5.50 2GB, 2CPU, 40GB, 500Mbps unmetered) brownrice ($5.95 3GB, 1CPU, 10GB, unlimited) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 7000 concurrent connections
Just try it! Tor will limit the amount of connections it accepts based on how much RAM you have. \ Original Message On Feb 20, 2024, 06:16, snowmanonahoe--- via tor-relays < tor-relays@lists.torproject.org> wrote: > > > > Hello all, > > > > > I'm interested in running a relay. I should meet all the requirements for a > guard/middle, except handling 7000 concurrent connections, which I'm unsure > of. The website seems to tell me to try it and see what happens, but what > exactly am I watching out for? Is the router going to fail entirely, slow > down, or something else? > > > > > Thanks in advance. > > > signature.asc Description: OpenPGP digital signature _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Getting spammed with 404 "Consensus is too old" warnings
Hello all, Obfs4 bridge. Here is the exact warning text:
Received http status code 404 ("Consensus is too old") from server
203.0.113.45:443 while fetching consensus directory. They appear in
irregular intervals between 2 and 45 minutes. The heartbeat messages indicate
the relay is working fine. The IP address is the same every time, and it's not
mine. Anything to worry about? _______
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] 7000 concurrent connections
Hello all, I'm interested in running a relay. I should meet all the requirements for a guard/middle, except handling 7000 concurrent connections, which I'm unsure of. The website seems to tell me to try it and see what happens, but what exactly am I watching out for? Is the router going to fail entirely, slow down, or something else?Thanks in advance. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] webtunnel bridge docker image still uses 0.4.7.13
Hi, with Tor version 0.4.7.x being EOL, the docker image for the webtunnel bridge deserves an update, as it still uses 0.4.7.13 ! Regards, C. -- Sent with https://mailfence.com Secure and private email___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] request for receipes MULTI-instances of ethe4 Guard, Bridge, Exits, snowflake , Tunnel, or both DEBIAN and OpenBSD
On 09/02/2024 00:48, admin--- via tor-relays wrote: You can have 2 separate relays on the same IPv4 address. Are you running into issues? It has been increased to 4 and then to 8 tor instances per IP address: https://forum.torproject.org/t/tor-relays-8-relays-pers-ip-address-are-allowed-from-now-end-of-june-2023-on/8192 Corl3ss ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] request for receipes MULTI-instances of ethe4 Guard, Bridge, Exits, snowflake , Tunnel, or both DEBIAN and OpenBSD
You can have 2 separate relays on the same IPv4 address. Are you running into issues? On Wednesday, February 7th, 2024 at 16:41, eff_03675...@posteo.se wrote: > > > > Hi, > > I have been looking too far and for too long on solving multiple > imstances / nodes per ONE IPv4, > and found only outdated problems unwell built. > > > Please when you have a bash sript / receipe, > I would welcome that. > > Hardening options would be very welcome too. > > > C. > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays signature.asc Description: OpenPGP digital signature _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Way to be notified when relay goes offline?
Does Tor Weather work with bridges? I have 2 bridges that have been operating for years and it says the fingerprints do not match any relays. I have been using Uptime Robot, but it would be cool to use Tor Weather. On Sunday, February 4th, 2024 at 21:33, mail--- via tor-relays wrote: > Hi, > >> Is there a way to be notified when a relay goes offline? Thanks. > > For a few relays you could make an account on weather.torproject.org and add > your email address and relays. But pretty much any other remote monitoring > tool will suffice as well. > > Cheers, > > tornth > > Feb 4, 2024, 22:30 by keifer@gmail.com: > >> Hi, >> >> So my relay at >> https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D >> went offline for a few days, and I was unaware. Is there a way to be >> notified when a relay goes offline? Thanks. >> --Keifer___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Way to be notified when relay goes offline?
Hi, > Is there a way to be notified when a relay goes offline? Thanks. For a few relays you could make an account on weather.torproject.org and add your email address and relays. But pretty much any other remote monitoring tool will suffice as well. Cheers, tornth Feb 4, 2024, 22:30 by keifer@gmail.com: > Hi, > > So my relay at > > https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D> > went offline for a few days, and I was unaware. Is there a way to be > notified when a relay goes offline? Thanks. > --Keifer > ___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay in AT marked as DE in metrics
Many thanks for your feedbacks - see https://bugzilla.ipfire.org/show_bug.cgi?id=13565 Regards - Carlo On Feb 1, 2024 at 8:44 PM, Martin Gebhardt via tor-relays wrote:>> I have a relay on 152.53.17.183 / 2a0a:4cc0:1:1333::beef which is listed as >> "German" in metrics.torproject.org, but actually it is in Austria > > Was just a topic here recently: > https://lists.torproject.org/pipermail/tor-relays/2024-January/021472.html > > Ask geofeed from the provider and submit a bug report. Your address is in netcups AS. We publish the geofeed here: https://opengeofeed.org/feed/as197540.html (CSV: https://opengeofeed.org/feed/as197540.csv) There you can also see that your network is correctly labelled as an Austrian IP in the geofeed: 152.53.16.0/22 the geofeed is also always kept up to date as it is stored at RIPE: https://apps.db.ripe.net/db-web-ui/query?searchtext=152.53.17.183 -- ahoy, Martin ___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sent with https://mailfence.com Secure and private email___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay in AT marked as DE in metrics
>> I have a relay on 152.53.17.183 / 2a0a:4cc0:1:1333::beef which is listed as >> "German" in metrics.torproject.org, but actually it is in Austria > > Was just a topic here recently: > https://lists.torproject.org/pipermail/tor-relays/2024-January/021472.html > > Ask geofeed from the provider and submit a bug report. Your address is in netcups AS. We publish the geofeed here: https://opengeofeed.org/feed/as197540.html (CSV: https://opengeofeed.org/feed/as197540.csv) There you can also see that your network is correctly labelled as an Austrian IP in the geofeed: 152.53.16.0/22 the geofeed is also always kept up to date as it is stored at RIPE: https://apps.db.ripe.net/db-web-ui/query?searchtext=152.53.17.183 -- ahoy, Martin ___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay in AT marked as DE in metrics
Hello, I have a relay on 152.53.17.183 / 2a0a:4cc0:1:1333::beef which is listed as "German" in metrics.torproject.org, but actually it is in Austria (see e.g. whatismyip.com) Is this the right place to request a fix ? Thanks, C. -- Sent with https://mailfence.com Secure and private email_______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay first seen reset on Tor metrics
The "first seen" date on my relay A00E3AAF5A24DC69740FA7A3A1C4A0ECB7972722 Got reset today while I was at work. It's not a problem and I don't particularly care, but is there anything that would cause this? IP hasn't changed, Tor version hasn't changed, etc. Thanks, Zachary_______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Setting up HTML page for exit relay
Hi, > If I want to serve an HTML page for my exit node do I need Apache2/nginx or > can I just modify my torrc? You don't need a dedicated webserver as long as unencrypted HTTP is acceptable. You can read more about the default HTML exit notice for Tor exit relays here: https://community.torproject.org/relay/setup/exit/. To quote: "To make it even more obvious that this is a Tor exit relay you should serve a Tor exit notice HTML page.Tor can do that for you: if your DirPort is on TCP port 80, you can make use of tor's DirPortFrontPage feature to display an HTML file on that port.This file will be shown to anyone directing their browser to your Tor exit relay IP address." And a sample HTML page can be found here: https://gitlab.torproject.org/tpo/core/tor/-/raw/HEAD/contrib/operator-tools/tor-exit-notice.html. But this doesn't scale well on many relays and doesn't provide TLS, so if you run many relays and/or want TLS I'd advise to still use a dedicated webserver (Apache, Nginx, Caddy etc.) that redirects to a single page on your Tor domain. For example, my IP addresses redirect to https://nothingtohide.nl/tor-relay/. Do note though that adding dedicated webservers to a OS that runs Tor also adds attack surface (both for hacking/breaching attempts and DDoS) and complexity. Make sure to harden and maintain it properly. For example with Apache the following setup might be acceptable: - Run it as a dedicated user - Disable ServerSignature - Production mode for ServerTokens - No mod_rewrite but basic Redirect 301 / https:// <https://nothingtohide.nl/tor-relay>domain.tld/tor-relay <http://domain.tld/tor-relay> - Disable any other unneeded modules - Disable directory listing - Disable access to all directories - HSTS and proper security headers - Use options such as -ExecCGI, -FollowSymlinks (or +SymLinksIfOwnerMatch if you really need it), -Includes etc. etc. And if DDoS becomes too big of a problem, you might also want to look in mitigation for that as well. Cheers and good luck! tornth Jan 29, 2024, 09:13 by tor-relays@lists.torproject.org: > > If I want to serve an HTML page for my exit node do I need Apache2/nginx or > can I just modify my torrc? > > ___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Setting up HTML page for exit relay
If I want to serve an HTML page for my exit node do I need Apache2/nginx or can I just modify my torrc? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Why is Cloudflare displayed when I do a speed test?
A blog post I discovered brought up that when they perform a speed test through Tor browser, Cloudflare is quite frequently displayed as the local host. I had the same result. Is there a reason for this, like perhaps the exit relay is proxied through Cloudflare? You can easily replicate this yourself by going to speedtest.net in Tor Browser. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay in Japan being marked as a US relay?
IP database are like phone books. They’re always accurate until they’re not. For positive confirmation you could always perform a traceroute. On Thu, 18 Jan 2024 21:07:30 GMT, 0tpcqovw--- via tor-relays tor-relays@lists.torproject.org wrote: https://www.infobyip.com/ip-198.13.48.219.html Shows Japan! Malcolm On Thu, Jan 18, 2024 at 4:00 PM NodNet wrote: I think tor and Tor Project use IPFire's DB for GeoIP lookups, and 198.13.48.219 shows the following: NETWORK: 198.13.48.0/20 AUTONOMOUS SYSTEM: AS20473 - AS-CHOOPA COUNTRY: United States of America https://www.ipfire.org/projects/location/lookup/198.13.48.219 On 1/18/2024 11:22 AM, Jag Talon wrote: > Hello, > > I have a relay in Japan with the IP of 198.13.48.219, but it's being > marked as being in the US. I've tried using different websites like > www.iplocation.net, iplocation.io, and www.wolframalpha.com and > they're all telling me that the IP is in Japan. > > I'm wondering if perhaps there's an issue with the GeoIP lookup? Or > perhaps an outdated database? > > Thanks! > > > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______ tor-relays mailing list tor-relays@lists.torproje ct.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays_______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay in Japan being marked as a US relay?
Hello, unfortunately this happens more often. you are not alone :-) > Am 18.01.2024 um 20:50 schrieb NodNet : > > I think tor and Tor Project use IPFire's DB for GeoIP lookups, and > 198.13.48.219 shows the following: Yes, libloc/location is used. I had the same problem with one or two relays years ago. This was then fixed by a manual override. This is currently also the case with 3 of my relays (37.252.255.135 / 37.252.254.33 / 217.146.2.41) However, I can't explain why. Because the hoster has a geofeed (https://opengeofeed.org/feed/as42473.html) and RIPE also has the correct country information. In any case, it is not so important to me that it is correct in the metrics. But it would be nice. Maybe I'll get round to mentioning it again on the location mailing list soon. Ahoy, Martin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay in Japan being marked as a US relay?
https://www.infobyip.com/ip-198.13.48.219.html Shows Japan! Malcolm On Thu, Jan 18, 2024 at 4:00 PM NodNet < tor_at_nodnetwork.org_0tpcq...@duck.com> wrote: > I think tor and Tor Project use IPFire's DB for GeoIP lookups, and > 198.13.48.219 shows the following: > > NETWORK: 198.13.48.0/20 > AUTONOMOUS SYSTEM: AS20473 - AS-CHOOPA > COUNTRY: United States of America > > https://www.ipfire.org/projects/location/lookup/198.13.48.219 > > On 1/18/2024 11:22 AM, Jag Talon wrote: > > Hello, > > > > I have a relay in Japan with the IP of 198.13.48.219, but it's being > > marked as being in the US. I've tried using different websites like > > www.iplocation.net, iplocation.io, and www.wolframalpha.com and > > they're all telling me that the IP is in Japan. > > > > I'm wondering if perhaps there's an issue with the GeoIP lookup? Or > > perhaps an outdated database? > > > > Thanks! > > > > > > ___ > > tor-relays mailing list > > tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay in Japan being marked as a US relay?
Hi, It is located in Tokyo, Japan. https://ipleak.net/?q=198.13.48.219 Mensagem original Em 18/01/2024 14:48, noury escreveu: > Hey, > > For what it's worth ipinfo.io says it's in Ōi, Saitama, Japan. > > https://ipinfo.io/198.13.48.219 > > On 18.01.24 18:22, Jag Talon wrote: > > Hello, > > > > I have a relay in Japan with the IP of 198.13.48.219, but it's being > > marked as being in the US. I've tried using different websites like > > www.iplocation.net, iplocation.io, and www.wolframalpha.com and > > they're all telling me that the IP is in Japan. > > > > I'm wondering if perhaps there's an issue with the GeoIP lookup? Or > > perhaps an outdated database? > > > > Thanks! > > > > > > ___ > > tor-relays mailing list > > tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > publickey - cauanzorzenon1@protonmail.com - 0x3C656E83.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A new kind of attack?
Hi > > I've noticed a new kind of possible attack on some of my relays, as > > early as Dec.23 which causes huge spikes of outbound traffic that > > eventually maxes out RAM and crashes Tor. The newest one today > > lasted for 5 hours switching between two of the three relays on the > > same IP. > > > > I have included charts and excerpts from the log in my post in Tor > > forum at below link: > > > > https://forum.torproject.org/t/new-kind-of-attack/11122 > > I've noticed this as well, on 0.4.8.10 across FreeBSD and Alpine > platforms, against relays too new to receive any meaningful traffic > from regular clients. MaxMemInQueues does not prevent the relay's > eventual saturation of available memory on the system. The relays > operated as exit nodes. > > We're low on memory (cell queues total alloc: 6336 buffer total > alloc: 1556480, tor compress total alloc: 1073827425 (zlib: 0, zstd: > 0, lzma: 1073827249), rendezvous cache total alloc: 0). Killing > circuits│withover-long queues. (This behavior is controlled by > MaxMemInQueues.) I attached what is a typical picture for my entry relays. Between normal and aggressive is a factor of 3-20 in circuits. The relay frontside (inbound) seems not impacted. Tor 0.4.8.9 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.7.3, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.5 and BSD 1302001 as libc. MaxMemInQueues 2 GB 2023-12-31, normal The relay takes 3216M memory and 9k files are open MM DD hh mm Circuits txGB rxGB ConnIp4rx ConnIp6rx ConnIp4tx ConnIp6tx 2023 12 31 00 55 41386 24 23 9165 563 2834 381 2023 12 31 01 55 39220 22 22 8550 472 2517 356 2023 12 31 02 55 38644 22 22 8411 456 2312 324 2023 12 31 03 55 40609 21 20 8650 496 2623 466 2023 12 31 04 55 37846 22 21 8424 504 3078 519 2023 12 31 05 55 35218 21 22 8210 457 2872 513 2023 12 31 06 55 35851 24 23 8126 472 2748 430 2023 12 31 07 55 35074 24 23 7971 404 2502 335 2023 12 31 08 55 34321 22 23 8069 448 2332 309 2023 12 31 09 55 35283 21 19 7909 430 1913 283 2023 12 31 10 55 33941 21 21 7709 457 1790 285 2023 12 31 11 55 33825 20 20 7643 484 1884 276 2023 12 31 12 55 32752 24 23 7328 474 1877 196 2023 12 31 13 55 32823 21 21 7333 511 1843 227 2023 12 31 14 55 29976 28 28 7058 473 1680 244 2023 12 31 15 55 28559 25 24 7096 503 1701 292 2023 12 31 16 55 28873 24 24 7217 493 1722 440 2023 12 31 17 55 29011 19 19 6994 487 1674 456 2023 12 31 18 55 32967 21 20 6710 455 1554 363 2023 12 31 19 55 28556 21 21 6714 450 1466 262 2023 12 31 20 55 27904 21 21 6558 384 1507 247 2023 12 31 21 55 27409 22 22 6130 390 1505 231 2023 12 31 22 55 26879 23 22 5929 390 1458 219 2023 12 31 23 55 25827 22 22 5627 376 1333 218 2024 01 01 00 55 28670 17 17 5955 451 1324 276 2024-01-11, aggressive The relay takes 7502M memory and 10k files are open MM DD hh mm Circuits txGB rxGB ConnIp4rx ConnIp6rx ConnIp4tx ConnIp6tx 2024 01 11 00 55 125285 30 30 12105 900 3399 648 2024 01 11 01 55 110064 30 29 11827 995 3725 790 2024 01 11 02 55 45423 24 22 13148 633 2549 543 2024 01 11 03 55 99047 21 20 12944 710 2363 444 2024 01 11 04 55 122485 23 22 11627 705 3623 543 2024 01 11 05 55 113557 23 23 9414 701 3842 709 2024 01 11 06 55 115456 23 23 9265 760 3980 934 2024 01 11 07 55 114597 22 22 9428 798 3733 904 2024 01 11 08 55 120269 27 27 10494 824 3652 702 2024 01 11 09 55 117867 27 25 9936 822 3774 740 2024 01 11 10 55 115923 31 31 9441 812 3734 752 2024 01 11 11 55 116081 28 28 9861 852 3850 714 2024 01 11 12 55 109707 25 24 10266 913 3639 659 2024 01 11 13 55 340445 48 29 15059 1750 3565 623 2024 01 11 14 55 637652 100 16 15583 1594 3886 824 2024 01 11 15 55 553291 100 13 10128 790 3410 700 2024 01 11 16 55 599953 97 16 19689 2965 3293 625 2024 01 11 17 55 559004 100 20 19513 3108 2743 545 2024 01 11 18 55 854193 90 18 51 664 3908 580 2024 01 11 19 55 752697 84 16 13 643 4069 749 2024 01 11 20 55 65342 47 8 17236 2092 2663 663 2024 01 11 21 55 42592 5 4 7842 334 2502 562 2024 01 11 22 55 118705 17 15 11781 781 4688 1169 2024 01 11 23 55 129431 23 23 12623 1145 4946 1128 2024 01 12 00 55 123173 22 21 13507 1154 4759 1119 -- Cheers, Felix pgpZsBCLxI6x5.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent Tor versions not reloading config on / ignoring HUP kill signal.
On 1/13/24 18:29, George Hartley via tor-relays wrote: Is anyone else experiencing this? Yes, https://gitlab.torproject.org/tpo/core/tor/-/issues/40749 -- Toralf ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay not connecting
Hi >Sorry, but I'm going to vent a little bit. I'm not a network >specialist, so 11 days ago I sent the following email to this > mailing list asking for help because two of my Tor exit relays were > completely frozen and I was unable to put them online again. According to https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B5881B7D4C97C the relay is back since 1-2 days, good. Exiting to port 22 might lead to a lot of complaints ending at your ISP or yourself. Default SSH. >Nobody answered, not even a comment. No wait, there was one person Unfortunately that happens from time to time. Thanks for your good report. Did you check https://gitlab.torproject.org/tpo/core/tor/-/issues/ for the bug you reported? > - very active on this mailing list recently - who sent me an email >personally to tell me that I was an idiot (referring to what, I > don't know) who should kill himself. Adding furthermore that if I > didn't commit suicide within 72 hours, he would personally come to my > house and kill me with a Glock 9 mm. Fun stuff, very disturbing. Nobody should read or write something like that. Makes me sad. >Anyway, no serious answers, someone calling me an idiot: I tried to >look as best as I could at what I did wrong. Couldn't find Again, nobody should read or write such. > anything. My only available solution was to rebuild completely my > server, something I wanted to do for a while because of other > undesired quirks that were bothering me with my setup. I knew it > would take a long time - which I didn't really have - but I finally > finished my new setup yesterday. (Don't look for > 25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57 or the bridge, they have > been shut down for the moment.) 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C is actually running >Today, I read a line from Chris Endiku-6 saying: "Thereâs > something going on for a while and I havenât seen any mentions of > it." The exact problem I mentioned! He says it goes "as early as > Dec.23"; my problem goes to Dec 18 as shown in my previous email. > Also, not mentioned in my previous email, before I renewed my setup, > my tor-ddos firewall rules (I use the ones from Endiku-6) had blocked > about 5 times more IP than usual - if that can be useful information > to anyone. Yeah, those things are the spices in our dish. Not sure yet if this is an attack. I observe it too and investigate on my end. Trying to understand the complex vector. >I still would like to know how to restart such a relay, if this > happens again in the future - other than reinstalling the entire > server, that is. Those are my questions too :) . Case by case and issue by issue. Stay save out there! -- Cheers, Felix pgpynMp81Z0qm.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A new kind of attack?
On 1/15/24 3:19 PM, Chris Enkidu-6 wrote: I've noticed a new kind of possible attack on some of my relays, as early as Dec.23 which causes huge spikes of outbound traffic that eventually maxes out RAM and crashes Tor. The newest one today lasted for 5 hours switching between two of the three relays on the same IP. I have included charts and excerpts from the log in my post in Tor forum at below link: https://forum.torproject.org/t/new-kind-of-attack/11122 I've noticed this as well, on 0.4.8.10 across FreeBSD and Alpine platforms, against relays too new to receive any meaningful traffic from regular clients. MaxMemInQueues does not prevent the relay's eventual saturation of available memory on the system. The relays operated as exit nodes. We're low on memory (cell queues total alloc: 6336 buffer total alloc: 1556480, tor compress total alloc: 1073827425 (zlib: 0, zstd: 0, lzma: 1073827249), rendezvous cache total alloc: 0). Killing circuits│withover-long queues. (This behavior is controlled by MaxMemInQueues.) -- Jordan Savoca https://jordan.im/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay that's been running for a long time suddenly saying it's new?
I had this issue too. It resolved itself shortly within a few hours. Original Message On Jan 15, 2024, 05:23, Petrarca via tor-relays wrote: > Just to confirm - the same happens to my relay, so this seems to be a general > issue. > > Keifer Bly schrieb am Montag, 15. Januar 2024 um 09:29: > >> Hi, >> >> So my relay at >> https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D >> is suddenly saying it's a new relay. Don't know why this would happen as >> it's been running for a few years, but suddenly saying it's new? >> >> Thanks. >> >> --Keifer___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay that's been running for a long time suddenly saying it's new?
Just to confirm - the same happens to my relay, so this seems to be a general issue. Keifer Bly schrieb am Montag, 15. Januar 2024 um 09:29: > Hi, > > So my relay at > https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D > is suddenly saying it's a new relay. Don't know why this would happen as > it's been running for a few years, but suddenly saying it's new? > > Thanks. > > --Keifer___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay that's been running for a long time suddenly saying it's new?
There seems to be an issue with the metrics page, mine(3A8D61AC59FD4F9AC7CC82B4B58FCC451578DC3B) has higher uptime than the first seen which is very interesting 樂 \ Original Message On Jan 15, 2024, 1:33 PM, Keifer Bly < keifer@gmail.com> wrote: > > > > Hi, > > > > > So my relay at > [https://metrics.torproject.org/rs.html\#details/79E3B585803DE805CCBC00C1EF36B1E74372861D][https_metrics.torproject.org_rs.html_details_79E3B585803DE805CCBC00C1EF36B1E74372861D] > is suddenly saying it's a new relay. Don't know why this would happen as > it's been running for a few years, but suddenly saying it's new? > > > > > Thanks. > > > > > \--Keifer [https_metrics.torproject.org_rs.html_details_79E3B585803DE805CCBC00C1EF36B1E74372861D]: https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D publickey - EmailAddress(s=tor@szaboaleks.xyz) - 0x2A931C00.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Recent Tor versions not reloading config on / ignoring HUP kill signal.
Hi,
I think this started with release 0.4.8.10, but both of my Tor relays no longer
reload their config when doing for example:
- systemctl reload tor@exit
Here is the relevant part of the unit file:
> [Unit]Description=Anonymizing overlay network for TCP
> After=syslog.target network.target nss-lookup.target
>
> [Service]
> Type=notify
> NotifyAccess=all
> ExecStartPre=/usr/bin/tor -f /etc/tor/torrc_%i --verify-config
> ExecStart=/usr/bin/tor -f /etc/tor/torrc_%i
> ExecReload=/bin/kill -HUP ${MAINPID}
> KillSignal=SIGINT
> TimeoutSec=75
> Restart=on-failure
> WatchdogSec=1m
> LimitNOFILE=32768
Checking with:
- journalctl -u tor@exit
Just tells me that systemd attempted and successfully executed the specified
reload command, but the actual line from the Tor instance stating that the
config has been reloaded is missing.
Is anyone else experiencing this?
Regards,
George
publickey - hartley_george@proton.me - 0xAEE8E00F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay’s first seen date got reset
I run the following relay: https://metrics.torproject.org/rs.html#details/6C336E553CC7E0416EBC8577A7289349B757F6C3. I just noticed that my relay’s ‘first seen’ date got reset. Tor now thinks that my relay is less than 2 weeks old. But when you open the 6 months graph, you can see the actual ‘first seen’ date which is November 29th 2023. Is it possible to fix this ‘first seen’ date back to the actual value? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [To the maintainers of Tor Metrics] Metrics showing erroneous data for my two relays, can somebody responsible please take a look at the issue?
Small update: Both metrics pages now show the correct family fingerprints, but the first seen date for the guard node is still wrong. It should be: 2023-11-26 05:00:00 (46 days 9 hours 10 minutes and 42 seconds) but it shows: 2024-01-10 16:00:00 (22 hours 14 minutes and 17 seconds) Everything else seems fixed. Regards, George On Thursday, January 11th, 2024 at 2:18 AM, George Hartley via tor-relays wrote: > Hello, > > for about 3 months I have been hosting two Tor relays: > > https://metrics.torproject.org/rs.html#details/AF42E6C77196A37F041A1A1E953E51B4656BDC1B > > > > https://metrics.torproject.org/rs.html#details/7F7D1A5BE88FA7C9358955705AE7AFA61EEDA2B0 > > > > 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 publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [To the maintainers of Tor Metrics] Metrics showing erroneous data for my two relays, can somebody responsible please take a look at the issue?
Hello, for about 3 months I have been hosting two Tor relays: https://metrics.torproject.org/rs.html#details/AF42E6C77196A37F041A1A1E953E51B4656BDC1B https://metrics.torproject.org/rs.html#details/7F7D1A5BE88FA7C9358955705AE7AFA61EEDA2B0 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 publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Worse throughput with 0.4.8.x, on a slow CPU
Also, it should not nearly be as frequent, it happens maybe every 30-45 minutes on my two relays (one guard, one exit). Try running Tor natively (you can just move it to a native Linux installation, by preserving the "`keys/ed25519_master_id_secret_key`" and `"keys/secret_id_key`" in your Tor DataDirectory). If you run a bridge, also backup and restore the "`pt_state`" directory into your new DataDirectory. Regards, George On Tuesday, January 9th, 2024 at 10:45 PM, George Hartley wrote: > Dear Jeff Blum, > > > > Yes, I am seeing something similar on 0.4.8.9 (and potentially earlier > > versions as well, not 100% sure when it started). I upgraded to 0.4.8.10 > > today hoping it would go away, but I'm seeing it again. Watching in nyx > > (screenshot of bandwidth graph attached), reliably every ~30 seconds. > > > This is just Tor doing zlib-compression on some documents, you can somewhat > combat it by assigning more cores to your machine. > > Tor is mostly singlethreaded, but OnionSkin decryption, zlib compression and > some other operations utilize all cores detected. > > Regards, > George > On Monday, January 8th, 2024 at 9:54 AM, Jeff Blum wrote: > > > > > > > > > On 12/13/23 06:15, Roman Mamedov wrote: > > > > > > > > > > > On the older version it gets about 80+80 Mbit total in+out. On the new > > > > one the > > > > average is at most 45+45 Mbit. There are frequent periods where the > > > > bandwidth > > > > drops to 5-10 Mbit for 3-5 seconds, while all Tor processes continue to > > > > use > > > > 100% of both CPUs, then gradually climbs back up. > > > > > > > > Does anyone notice anything similar? > > > > Hi Roman, > > > > Yes, I am seeing something similar on 0.4.8.9 (and potentially earlier > > versions as well, not 100% sure when it started). I upgraded to 0.4.8.10 > > today hoping it would go away, but I'm seeing it again. Watching in nyx > > (screenshot of bandwidth graph attached), reliably every ~30 seconds, I see > > the bandwidth briefly plummet and the tor process CPU spike. Guard relay > > running in docker under ubuntu server on a Ryzen 3600 machine with 32GB > > RAM. Note that when the relay restarted after the upgrade today, it didn't > > do this for a while (maybe an hour or so? wasn't watching it the whole > > time), but then started glitching every 30s. Once it starts it does this > > every ~30 seconds forever. Relay has been running like this for weeks, > > maybe months. > > > > best, > > > > -jeff > > > > publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Worse throughput with 0.4.8.x, on a slow CPU
Dear Jeff Blum, > Yes, I am seeing something similar on 0.4.8.9 (and potentially earlier > versions as well, not 100% sure when it started). I upgraded to 0.4.8.10 > today hoping it would go away, but I'm seeing it again. Watching in nyx > (screenshot of bandwidth graph attached), reliably every ~30 seconds. This is just Tor doing zlib-compression on some documents, you can somewhat combat it by assigning more cores to your machine. Tor is mostly singlethreaded, but OnionSkin decryption, zlib compression and some other operations utilize all cores detected. Regards, George On Monday, January 8th, 2024 at 9:54 AM, Jeff Blum wrote: > > > > On 12/13/23 06:15, Roman Mamedov wrote: > > > > > > > > On the older version it gets about 80+80 Mbit total in+out. On the new > > > one the > > > average is at most 45+45 Mbit. There are frequent periods where the > > > bandwidth > > > drops to 5-10 Mbit for 3-5 seconds, while all Tor processes continue to > > > use > > > 100% of both CPUs, then gradually climbs back up. > > > > > > Does anyone notice anything similar? > > Hi Roman, > > Yes, I am seeing something similar on 0.4.8.9 (and potentially earlier > versions as well, not 100% sure when it started). I upgraded to 0.4.8.10 > today hoping it would go away, but I'm seeing it again. Watching in nyx > (screenshot of bandwidth graph attached), reliably every ~30 seconds, I see > the bandwidth briefly plummet and the tor process CPU spike. Guard relay > running in docker under ubuntu server on a Ryzen 3600 machine with 32GB RAM. > Note that when the relay restarted after the upgrade today, it didn't do this > for a while (maybe an hour or so? wasn't watching it the whole time), but > then started glitching every 30s. Once it starts it does this every ~30 > seconds forever. Relay has been running like this for weeks, maybe months. > > best, > > -jeff > > publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Remove my relay from relay search on Tor Metrics
7 d a y s. On Monday, January 8th, 2024 at 9:54 AM, 0tpcqovw--- via tor-relays wrote: > I think it's after 30 days it gets automatically removed. > Malcolm > > > On Mon, Dec 25, 2023, 15:25 nemeto via tor-relays > wrote: > > > DuckDuckGo did not detect any trackers. > > > > Hi, > > I set up a middle relay at first, but I changed my mind to run a bridge to > > avoid blacklisting of my public IP by certain websites. > > > > Is it possible to immediately remove my relay from relay search on Tor > > Metrics? If not, when will my relay be removed from the relay list? > > > > Thanks! > > > > Nemeto > > ___ > > tor-relays mailing list > > tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Remove my relay from relay search on Tor Metrics
I think it's after 30 days it gets automatically removed. Malcolm On Mon, Dec 25, 2023, 15:25 nemeto via tor-relays < tor-relays_at_lists.torproject.org_0tpcq...@duck.com> wrote: > Hi, I set up a middle relay at first, but I changed my mind to run a > bridge to avoid blacklisting of my public IP by certain websites. Is it > possible to immediately remove my relay from relay search o > *DuckDuckGo* did not detect any trackers. More > <https://duckduckgo.com/> > Deactivate > <https://duckduckgo.com/> > Hi, > > I set up a middle relay at first, but I changed my mind to run a bridge to > avoid blacklisting of my public IP by certain websites. > > Is it possible to immediately remove my relay from relay search on Tor > Metrics? If not, when will my relay be removed from the relay list? > > Thanks! > > Nemeto > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Remove my relay from relay search on Tor Metrics
Thanks for your answers guys, I keep you informed. Happy holidays to all Nemeto Le mar. 26 déc. 2023 à 06:45, George Hartley via tor-relays <[tor-relays@lists.torproject.org](mailto:Le mar. 26 déc. 2023 à 06:45, George Hartley via tor-relays < a écrit : > - Is it possible to immediately remove my relay from relay search on Tor > Metrics? > > No. > > - If not, when will my relay be removed from the relay list? > > Generally 7 days after your relay last uploaded it's descriptor. > > Happy holidays, > > George > On Sunday, December 24th, 2023 at 11:10 AM, nemeto via tor-relays > wrote: > >> Hi, >> >> I set up a middle relay at first, but I changed my mind to run a bridge to >> avoid blacklisting of my public IP by certain websites. >> >> Is it possible to immediately remove my relay from relay search on Tor >> Metrics? If not, when will my relay be removed from the relay list? >> >> Thanks! >> Nemeto___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Remove my relay from relay search on Tor Metrics
- Is it possible to immediately remove my relay from relay search on Tor Metrics? No. - If not, when will my relay be removed from the relay list? Generally 7 days after your relay last uploaded it's descriptor. Happy holidays, George On Sunday, December 24th, 2023 at 11:10 AM, nemeto via tor-relays wrote: > Hi, > I set up a middle relay at first, but I changed my mind to run a bridge to > avoid blacklisting of my public IP by certain websites. > > Is it possible to immediately remove my relay from relay search on Tor > Metrics? If not, when will my relay be removed from the relay list? > > Thanks! > > Nemeto publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Remove my relay from relay search on Tor Metrics
Hi, I set up a middle relay at first, but I changed my mind to run a bridge to avoid blacklisting of my public IP by certain websites. Is it possible to immediately remove my relay from relay search on Tor Metrics? If not, when will my relay be removed from the relay list? Thanks! Nemeto___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay data limit
Hi Dan, that would have been my first choice as well. Now with the additional traffic available to you, you can still rate-limit the relay to a relatively usable speed and not get throttled at all. Let me know, I'd like to know some of your traffic statistics, just to see how your relay performs. If you would like, you can link me your Tor Metrics link privately. Thank you for supporting the Tor network! All the best, George On Friday, December 22nd, 2023 at 4:30 PM, Dan wrote: > Hi George, > > Thanks for all the input. > > > Or, just ask the provider for more bandwidth per month, generally now in > > 2023 it's pretty damn cheap. > > > I had not considered this, but when contacted my VPS provider offered another > 5TB for an additional $3/month. Considering the box only costs $4/month, I > think this is the best option. > > I'll probably remove all limits for January and just see how much traffic > gets transferred. > > --- > Thanks, > Dan > > On Thursday, December 21st, 2023 at 8:04 AM, George Hartley via tor-relays > tor-relays@lists.torproject.org wrote: > > > > > Hi Dan, > > > > > 1 - Is it better for the network if the relay is active 24/7, even if > > > sometimes it's much slower? > > > > Generally according to the relay requirements a relay is considered useful > > if it can at least route 2MB/s or 16 MBit/s steadily. > > > > However, I think you should get away with 1MB/s or 8 MBit/s. > > > > > 2 - Will it negatively affect my relay's reputation if sometimes it's > > > very slow? > > > > The Tor authorities might reduce your middle probability, but you will not > > be punished in any way, and as soon as automatic bandwidth measurements > > confirm that you have more capacity available, > > > > the authorities should start directing more traffic to your relay. > > > > Some possible other ideas: > > > > Rate-limit traffic to your relay using RelayBandwidthRate and > > RelayBandwidthBurst, but with only 5TB of monthly traffic you will end up > > rate-limiting it to somewhere in the 1,8 to 2MB/s range to not hit your > > traffic cap. > > > > Or, just ask the provider for more bandwidth per month, generally now in > > 2023 it's pretty damn cheap. > > > > All the best, > > George > > > > > Hi all, > > > > > > I've been running a middle relay on a VPS for about 2 months now. The > > > provider limits the monthly data transferred to 5TB but does not charge > > > for over-usage. Instead, the bandwidth is throttled to 1Mb/s after the > > > limit is reached until the 1st of the next month. > > > > > > I currently have AccountingMax set to 2.5 TB (since it's the max in each > > > direction) and AccountingStart set to "month 1 00:00". Generally that 5TB > > > limit is hit between the 15th and 17th of the month, causing the relay to > > > go dormant until the 1st. > > > > > > What I'm wondering is: > > > > > > 1 - Is it better for the network if the relay is active 24/7, even if > > > sometimes it's much slower? > > > 2 - Will it negatively affect my relay's reputation if sometimes it's > > > very slow? > > > > > > Thank you > > > > > > -- > > > Dan > > > > > > _______ > > > tor-relays mailing list > > > tor-relays@lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay data limit
Hello Dan,> I'll probably remove all limits for January and just see how much traffic gets transferred.I would highly advise against this since you are using VPS with a capped bandwidth plan. Tor will use all of the bandwidth you give it. Therefore if you remove all limits that may lead to complaints and possible suspension from your hosting provider regarding your high bandwidth usage and affecting other clients on the same node. publicKey - Concept@proton.me - 0x30665F1F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor: tor_bug_occurred_(): Bug: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10)
Hello, this just happened again 5 days after the update to 0.4.8.10: > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > tor_bug_occurred_(): Bug: src/core/or/conflux.c:567: conflux_pick_first_leg: > Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 > )Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: Tor > 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in > conflux_pick_first_leg at src/core/or/conflux.c:567. Stack trace: (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(log_backtrace_impl+0x5d) [0x57b884d219ad] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(tor_bug_occurred_+0x194) [0x57b884d38764] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x57b884dd74ee] (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(circuit_get_package_window+0x6d) [0x57b884ddf7fd] (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(+0x9bc59) [0x57b88459] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x57b884ccce39] (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x57b884df9a46] (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(+0x1c03f8) [0x57b884df13f8] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(+0x6e72d) [0x57b884c9f72d] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/lib/libevent-2.1.so.7(+0x22c45) [0x73761346dc45] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x73761346f3af] (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(do_main_loop+0x104) [0x57b884c9ff44] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(tor_run_main+0x215) [0x57b884ca4165] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(tor_main+0x5e) [0x57b884ca45ee] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(main+0x1d) [0x57b884c9608d] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/lib/libc.so.6(+0x27cd0) [0x737612a7ecd0] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x737612a7ed8a] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: > /usr/bin/tor(_start+0x25) [0x57b884c960e5] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > conflux_log_set(): Bug: Conflux C0292D60501F6C5F: 0 linked, 0 launched. > Delivered: 29; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > conflux_log_set(): Bug: Conflux C0292D60501F6C5F: 0 linked, 0 launched. > Delivered: 29; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit > 0x57b898679070 idx 522 marked at line src/core/or/command.c:663 (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] > tor_bug_occurred_(): Bug: src/core/or/conflux.c:567: conflux_pick_first_leg: > Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 > ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: Tor > 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in > conflux_pick_first_leg at src/core/or/conflux.c:567. Stack trace: (on Tor > 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558
Re: [tor-relays] Relay data limit
Hi Dan, >1 - Is it better for the network if the relay is active 24/7, even if >sometimes it's much slower? Generally according to the relay requirements a relay is considered useful if it can at least route 2MB/s or 16 MBit/s steadily. However, I think you should get away with 1MB/s or 8 MBit/s. > 2 - Will it negatively affect my relay's reputation if sometimes it's very >slow? The Tor authorities might reduce your middle probability, but you will not be punished in any way, and as soon as automatic bandwidth measurements confirm that you have more capacity available, the authorities should start directing more traffic to your relay. Some possible other ideas: Rate-limit traffic to your relay using RelayBandwidthRate and RelayBandwidthBurst, but with only 5TB of monthly traffic you will end up rate-limiting it to somewhere in the 1,8 to 2MB/s range to not hit your traffic cap. Or, just ask the provider for more bandwidth per month, generally now in 2023 it's pretty damn cheap. All the best, George > Hi all, > > I've been running a middle relay on a VPS for about 2 months now. The > provider limits the monthly data transferred to 5TB but does not charge for > over-usage. Instead, the bandwidth is throttled to 1Mb/s after the limit is > reached until the 1st of the next month. > > I currently have AccountingMax set to 2.5 TB (since it's the max in each > direction) and AccountingStart set to "month 1 00:00". Generally that 5TB > limit is hit between the 15th and 17th of the month, causing the relay to go > dormant until the 1st. > > What I'm wondering is: > > 1 - Is it better for the network if the relay is active 24/7, even if > sometimes it's much slower? > 2 - Will it negatively affect my relay's reputation if sometimes it's very > slow? > > Thank you > > -- > Dan > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dutch Relays
On 12/18/23 6:59 AM, ab...@relayon.org 2023 wrote: These are complete and utter shit. avoid like the plague! nifty Oh? I'm curious to hear more about your reasons/experience, if you're open to sharing. They're pretty well-regarded in networking spaces. -- Jordan Savoca https://jordan.im/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Declining Relay Usage
Please read the code, not only Tor's code, but also OpenSSL's code. Yes, AES is not displayed as engine itself, however, it still does not seem to use aes-ni instructions unless told to initialize engines via the code I deducted. If this proves anything, I ran an Exit Relay in 2013 before my host forced me to switch to a Guard one because of excessive abuse, and even though my VM supported aesni instructions, OpenSSL would not actually use them until I added the config parameter, the peak CPU usage (single core) dropped from 88-95% avg to around 23% avg once I added it. Maybe some developer can comment on the deeper workings of OpenSSL and Tor, and terminology might get weird between the Tor and OpenSSL (both very big code-bases). Also, regarding the e-mail, I post regularly on here and tor-dev, so no worries :) Let's just end this pointless discussion here, I will do some more research the next few days because I actually want to know, but to me everything seems pretty clear (from the code I've YET SEEN, not the one I DID NOT YET SEE). Peace, friend. P.S: I included the tor-dev mailing list to my recipients, they should be more knowledgeable, I am just an employed C/C++ programmer on mostly Windows and POSIX-compatible systems, with a little over 15 years of experience, with some reverse engineering experience on both PE and MACHO binaries (x86 & x64). > On Mon, 18 Dec 2023 15:58:52 + > George Hartley hartley_geo...@proton.me wrote: > > > I had a quick look at the manual, and it stated: > > > > > HardwareAccel 0|1 > > > > > If non-zero, try to use built-in (static) crypto hardware acceleration > > > > when available. Can not be changed while tor is running. (Default: 0) > > > > A quick look at the source code tells me that Tor relies entirely on > > OpenSSL. > > > > The call-chain here is as follows: > > > > crypto_set_options first determines whether to enable any available OpenSSL > > engines based on if the variable mentioned above is non-zero or if an > > accelerator name has been set: > > > > > const bool hardware_accel = options->HardwareAccel || options->AccelName; > > > > This bool is then passed into crypto_global_init, where it is the first > > argument, fittingly named "useAccel". > > > > useAccel is then passed into crypto_openssl_late_init, where if > > HardwareAccel is the default (0) or no engine name has been specified, > > OpenSSL will make no attempt to load any acceleration engines. > > > > Here is a permalink to that last relevant function in the call chain: > > > > https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/lib/crypt_ops/crypto_openssl_mgt.c?ref_type=heads#L382 > > > > So yes, I think it is pretty safe to assume that if you do not set either > > configuration option, no OpenSSL engine will be used. > > > > Thank you for questioning me though, thanks to you I learned some more > > about Tor's inner workings, and you hopefully too :) > > > It is not entirely clear to me what conclusion you came to after this > research. If you mean that HardwareAccel is needed, I would still disagee. > > If I'm not mistaken the AES-NI support is implemented in OpenSSL not via an > "engine" that you have to "use", it is just built-in internally on some deeper > level. For a proof you can run "openssl engine" in the console of any > AES-supporting machine, and you will not see any loadable engines there, aside > from rdrand, which is unrelated, and "dynamic" which just means it can load > some acceleration engines if it had any. And for instance VIA Padlock would > show up as "padlock" in that list. > > Please use reply to all the mailing list. Sorry for bringing out your mail > into the public, but it didn't seem to be strictly private in any case. > > -- > With respect, > Roman > ___________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay operator meetups
Hey telekobold, > will there be a Tor relay operators meetup @37C3 [*]? There seems to be a Tor meetup as SoS (Self-organized session) by Q Misell: https://events.ccc.de/congress/2023/hub/en/event/tor-meetup fossdd signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Declining Relay Usage
Hello Likogan (you did not specify a name, so I just took your domain name). First, lets look at issue number one: If your Tor Exit is using ~50% of the entire CPU (VM or dedicated server?) while only routing 6 Mbps, then you are likely not using hardware AES acceleration (aesni). For example, my Tor Exit node only uses 15-25% of a single core while easily routing 10 to 12 Megabytes per second. All on the following CPU: Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz with a maximum boost clock of 2.50 GHz. Try the following command: lscpu | grep aes If the command returns nothing, sadly your CPU does not support hardware AES acceleration, or if you run your OS in a VM, then the VM operator likely did not set "host" as CPU model. If however the command does output a list of flags, with aes highlighted in red (depends on SSH client), then you can safely add the following line to your nodes configuration file: > HardwareAccel 1 General specs about your server, including the full output from lscpu would also be nice, if you are on a 10GbE link, then I assume it is a dedicated server, and a relatively new one (hardware wise) at that. Now lets look at your traffic provider, or it's AS number: https://metrics.torproject.org/rs.html#search/as:AS53667 We can see right away that this host is very congested with Tor nodes already (around 230 nodes in their datacenters right now), and thus the Tor authorities might route less traffic through it in general - decentralization is ALWAYS better! I actually don't know if the Tor authorities act that way, maybe someone with more knowledge can chime in. So yes, here is a too long, didn't read for you: Check for aesni support as explained above, if it exists, please add the mentioned config entry, and just to make sure, the NumCPUs variable with the amount of your logical CPU cores. Also, even if Tor's code base is mostly single-threaded, there are a few tasks that can be offloaded to different cores, such as onionskin decryption, zlib compression, etc. If you have some spare CPU cores, please let Tor offload as much work as possible by, as said above, adding the > NumCPUs variable to your nodes configuration. This generally is not necessary as Tor will try to detect the amount of cores automatically, but in a locked down environment, such as mine, it wouldn't work :) Hope this helps you or others, George P.S: My e-mail web-client always auto-attaches my PGP public key, so if you (or others) want to talk to me privately, that option exists too, however it shouldn't be needed in this case. All the best and thank you so much for hosting an exit relay! > My exit relay has seen steadily decreasing traffic from 8MBps to 6MBps > over the span of three weeks. It averages a load of ~50% CPU usage and > ~65% RAM usage. It's rated network capacity is 17Mbps on a 10GB link. > Why would traffic decrease if I have plenty of spare resources? Are > there ways I can configure my server to boost traffic? > > https://metrics.torproject.org/rs.html#details/292FCACE773DC259B799914A23BE65A6A6178E8F > > > > ___________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Declining Relay Usage
My exit relay has seen steadily decreasing traffic from 8MBps to 6MBps over the span of three weeks. It averages a load of ~50% CPU usage and ~65% RAM usage. It's rated network capacity is 17Mbps on a 10GB link. Why would traffic decrease if I have plenty of spare resources? Are there ways I can configure my server to boost traffic? <https://metrics.torproject.org/rs.html#details/292FCACE773DC259B799914A23BE65A6A6178E8F> _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor: Possible bug on 0.4.8.9 exit relay.
Hi, while going through journalctl I noticed the following entries from my exit relay and wanted to report this non-fatal assertion. I also host a Guard relay on the same VM and IP, and it did not yet assert that message. The full assert() with the stack-trace is as follows: > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > tor_bug_occurred_(): Bug: src/core/or/conflux.c:565: conflux_pick_first_leg: > Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.9 > )Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: Tor > 0.4.8.9: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in > conflux_pick_first_leg at src/core/or/conflux.c:565. Stack trace: (on Tor > 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(log_backtrace_impl+0x5d) [0x5fdf47b6a9ad] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(tor_bug_occurred_+0x194) [0x5fdf47b81764] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x5fdf47c2031e] (on Tor 0.4.8.9 > ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(circuit_get_package_window+0x6d) [0x5fdf47c285ed] (on Tor > 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(+0x9bc59) [0x5fdf47b15c59] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x5fdf47b15e39] (on Tor > 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x5fdf47c42866] (on Tor > 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(+0x1c0218) [0x5fdf47c3a218] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(+0x6e72d) [0x5fdf47ae872d] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/lib/libevent-2.1.so.7(+0x22c45) [0x7d444a49cc45] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7d444a49e3af] (on Tor > 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(do_main_loop+0x104) [0x5fdf47ae8f44] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(tor_run_main+0x215) [0x5fdf47aed165] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(tor_main+0x5e) [0x5fdf47aed5ee] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(main+0x1d) [0x5fdf47adf08d] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/lib/libc.so.6(+0x27cd0) [0x7d4449a7ecd0] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7d4449a7ed8a] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: > /usr/bin/tor(_start+0x25) [0x5fdf47adf0e5] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. > Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 > ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. > Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 > ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit > 0x5fdf581d3460 idx 4524 marked at line src/core/or/command.c:663 (on Tor > 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] > tor_bug_occurred_(): Bug: src/core/or/conflux.c:565: conflux_pick_first_leg: > Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: Tor 0.4.8.9: > Non-fata
Re: [tor-relays] Running a high-performance pluggable transports Tor bridge (FOCI 2023 short paper)
Hi David > https://www.bamsoftware.com/papers/pt-bridge-hiperf/ > > https://www.youtube.com/watch?v=UkUQsAJB-bg=PLWSQygNuIsPc8bOJ2szOblMK4i6T79S1m=5 > > The other FOCI 2023 issue 2 videos are online as well: > > https://www.youtube.com/playlist?list=PLWSQygNuIsPc8bOJ2szOblMK4i6T79S1m Thank you for the paper and the presentation. Chapter 3 (Multiple Tor processes) shows the structure: > mypt - HAproxy = multiple tor services At the end of chapter 3.1 it is written > the loss of country- and transport-specific metrics How will the metrics data be pulled out of the multiple tor services to fetch *all* metrics data? Or will only one of them be looked at, without full data representation? I ask primary about an obfs4 setup. Which might apply for snowflake and friends too. -- Cheers, Felix pgp3tdqG4uTGv.pgp Description: Digitale Signatur von OpenPGP _______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dutch Relays
On 12/10/23 2:41 PM, Christopher Sheats wrote: Emerald Onion is looking for co-location and IP transit opportunities in the Netherlands for deploying new exit relays. We have our own ASN, v4 and v6 IP space. Hi yawnbox, You may want to check out ColoClue[1], they're a volunteer-based not-for-profit association operated by folks in the commercial ISP space who needed a way to host their own systems. Today they support ~200 engineering hobbyists with low-cost infrastructure. They have cross-connects to AMS-IX and NL-IX[2] and diverse transit connectivity[3] in their racks. Job Snijders has given a couple talks at NLNOG and NANOG about operations-related things, like effective DDoS mitigation[4] with fastnetmon and automated peering solutions[5]. I'm not a member personally, but if I lived in the area I'd definitely include them in my list of potential options. ^^ [1]: https://coloclue.net/en/ [2]: https://github.com/coloclue/peering/blob/master/peers.yaml [3]: https://bgp.tools/as/8283#connectivity [4]: https://www.youtube.com/watch?v=0ahdxp_btHY [5]: https://www.youtube.com/watch?v=C7pkab8n7ys -- Jordan Savoca https://jordan.im/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit operators on the 0.4.8.x series, please upgrade to 0.4.8.10 ASAP!
We would appreciate if the tor project could coordinate better with deb.torproject.org debian package updates to reduce the time between a release and the availability of packages on deb.torproject.org. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay question
On 12/8/23 04:19, Mulloch94 via tor-relays wrote: -A INPUT -j DROP HHm, what's about local traffic, e.g.: -A INPUT --in-interface lo -j ACCEPT or ICMP, e.g.: -A INPUT -p icmp -j ACCEPT To persist your firewall rules take a look at this doc [1] [1] https://github.com/toralf/torutils#quick-start -- Toralf ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay question
Greetings, I was directed to this relay subscription by the owner. I've recently started my own relay and everything has went smooth for the first few days. Then the relay mysteriously went offline for a period of 8-9 hours. Happened while I was sleeping I think, but any rate it came back on after I restarted the tor daemon and rebooted the server. I'm starting to think my firewall configurations might have been the culprit, even though I ran a very rudimentary setup. Basically just: -A INPUT -p tcp --dport -j ACCEPT -A INPUT -p tcp --dport 9050 -j ACCEPT -A INPUT -p tcp --dport 443 -j ACCEPT -A INPUT -p tcp --dport 80 -j ACCEPT -A INPUT -j DROP Default ACCEPT on OUTPUT My ORPort is on 443, so I don't see how this could be interfering. I noticed my server reboot got rid of all my rules, so I'm thinking that could've been the issue. If so, what other ports should I add? Do I even need a firewall for the relay? I don't do anything else with that server, so If it doesn't need a firewall to stay secure I won't use one. One more thing, I had a flag on my relay that said I needed to "update the descriptor." It went away after rebooting my server as well, could that been the issue? Sent with [Proton Mail](https://proton.me/) secure email._______ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Correction to Good Bad ISPs, UK
Hi, This is probably the wrong place but here is a minor update to the Good / Bad ISPs page: http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay/community-resources/good-bad-isps/index.html The company HostWorld in the UK does allow guard and middle relays but just refused me permission to change mine to an exit node. That's today, 2023-12-02. They're pretty good, I've had no problems, efficient customer support, unlimited bandwidth, but 'no' to exit relays. I don't know about bridges. ASN : AS42831. regards,___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
