Re: [tor-relays] disable conflux on exit relay?
Hi, On 4/14/24 16:17, applied-privacy.net via tor-relays wrote: 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. Thanks for reporting this. I have opened https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/815 to fix it. I was wondering if you had disabled conflux for any of your relays, and if this was the case what we could do to help you and have you re-enable it again. Talk soon, -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
Re: [tor-relays] Webtunnel type bridge Tor Metrics
Hey, On 4/25/24 09:02, Bauruine wrote: On 24.04.24 19:31, tor-home at encryptfirst.com wrote: 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 Yes that's the reason. There is an issue that this should be documented https://gitlab.torproject.org/tpo/web/community/-/issues/329 The bridgestrap test was not completely fixed it seems: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/199#note_3023649 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
Re: [tor-relays] Webtunnel type bridge Tor Metrics
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
Re: [tor-relays] Webtunnel type bridge Tor Metrics
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
Re: [tor-relays] issues with tor-nightly-main repo
Hi, On 4/18/24 05:04, applied-privacy.net via tor-relays wrote: 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 This is maintained by a debian developer. I'll ping and see if the person has time soon to fix it. Cheers, -hiro 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 ___ 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?
Hi, On 4/5/24 23:47, applied-privacy.net via tor-relays wrote: 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. Conflux was a big change for the network and there are still some bugs that we are trying to solve. At the same time it has made things significantly better for users and it wouldn't be ideal if you disable it on all your relays. We would rather work with you to help you run your relays smoothly. When you mention crashes are you referring to issue: https://gitlab.torproject.org/tpo/core/tor/-/issues/40921? Has this been happening again since? Let me know. Cheers, -hiro 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Odd network activity
Hi all, I can now confirm the data has been restored and no relay or bridge should exhibit any bump in traffic due to this but. Cheers, -hiro On 4/3/22 15:11, Silvia/Hiro wrote: On 4/3/22 11:40, Eldalië via tor-relays wrote: Thanks very much. The anomalous peaks disappeared for most of the days indeed, it remained only for 26/02. Yes, working to fix the bump for 26/02. -hiro Eldalië On Fri, 4 Mar 2022 07:26:26 + Georg Koppen wrote: Eldalië via tor-relays: Hello there. I see on every exit node I check on the metrics page, a massive bump in bandwidth used without a change in exit probability. I just checked the metrics page for the relay I operate (791E637A38C715336290E8AC0EB6C99BD02A5F0E) and I noticed a bump similar to the one from FDAA4F76F778215F02B0B02DCE8E8504179BCDC6. However, my relay is not and has never been an exit relay. Also, it looks like the data changed retroactively: I usually check the metrics about once a day and I'm sure I would have noticed the peak of 26/02 the day after - I mean, it is a more than x3 increment from the day before (that also had the highest value ever until then). Should I worry about that? And should I report my own relay to the bad-relays mailing list? No, it's fine. I am not sure yet what the problem is but I suspect it's a bug in one of our recent code changes. See: https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40022#note_2783524 for more details. We've reverted that change for now and things should normalize again assuming the traffic increase you see is indeed related to it. Georg Thanks for the help. Eldalië On Thu, 03 Mar 2022 19:01:37 + awffelwaffels via tor-relays wrote: I see on every exit node I check on the metrics page, a massive bump in bandwidth used without a change in exit probability. Is this perhaps an attacker squeezing the bandwidth of the network so people are more likely to use their malicious nodes? ___ 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] Odd network activity
On 4/3/22 11:40, Eldalië via tor-relays wrote: Thanks very much. The anomalous peaks disappeared for most of the days indeed, it remained only for 26/02. Yes, working to fix the bump for 26/02. -hiro Eldalië On Fri, 4 Mar 2022 07:26:26 + Georg Koppen wrote: Eldalië via tor-relays: Hello there. I see on every exit node I check on the metrics page, a massive bump in bandwidth used without a change in exit probability. I just checked the metrics page for the relay I operate (791E637A38C715336290E8AC0EB6C99BD02A5F0E) and I noticed a bump similar to the one from FDAA4F76F778215F02B0B02DCE8E8504179BCDC6. However, my relay is not and has never been an exit relay. Also, it looks like the data changed retroactively: I usually check the metrics about once a day and I'm sure I would have noticed the peak of 26/02 the day after - I mean, it is a more than x3 increment from the day before (that also had the highest value ever until then). Should I worry about that? And should I report my own relay to the bad-relays mailing list? No, it's fine. I am not sure yet what the problem is but I suspect it's a bug in one of our recent code changes. See: https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40022#note_2783524 for more details. We've reverted that change for now and things should normalize again assuming the traffic increase you see is indeed related to it. Georg Thanks for the help. Eldalië On Thu, 03 Mar 2022 19:01:37 + awffelwaffels via tor-relays wrote: I see on every exit node I check on the metrics page, a massive bump in bandwidth used without a change in exit probability. Is this perhaps an attacker squeezing the bandwidth of the network so people are more likely to use their malicious nodes? ___ 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] Odd network activity
On 3/3/22 20:01, awffelwaffels via tor-relays wrote: I see on every exit node I check on the metrics page, a massive bump in bandwidth used without a change in exit probability. Is this perhaps an attacker squeezing the bandwidth of the network so people are more likely to use their malicious nodes? Hi, This was a bug that was briefly introduced between yesterday afternoon and early morning today (UTC times). I have reverted the commit this morning around 5.00 AM (UTC) so you should start seeing your graphs back to normal. Thanks for noticing and apologies for that. Cheers, -hiro ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Outdated GeoIP DB
On 21/1/22 12:15, Valters Jansons wrote: > On Fri, Jan 21, 2022 at 1:05 PM Georg Koppen wrote: >> Yes, we realized that the GeoIP db needs an update again[1]. However >> there is currently no newer version available[2] it seems. :( > The issue is not the version of libloc. The problem resides in an > outdated local database. The library and binaries are not the same > project/build as the database project[1], which gets updated daily. > The database is not being updated for Tor. > > If you check the current lookup for the mentioned IP[2], it results in: > - Network: 89.58.16.0/22 > - Announced by: AS197540 - netcup GmbH > - Country: Austria > This seems to be correct, like Martin said it should be. > > [1] https://git.ipfire.org/?p=location/location-database.git;a=summary > [2] https://location.ipfire.org/lookup/89.58.17.76 Hey Valters, We run the update command daily and sync the data from it. See: https://man-pages.ipfire.org/libloc/location.html As far as I understand this should update the local DB. Are we overlooking something? 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
Re: [tor-relays] Overloaded state indicator on relay-search
On 10/4/21 1:36 PM, David Goulet wrote: > On 02 Oct (01:29:56), torix via tor-relays wrote: >> My relays (Aramis) marked overloaded don't make any sense either. Two of >> the ones marked with orange are the two with the lowest traffic I have (2-5 >> MiB/s and 4-9 MiB/s - not pushing any limits here); the third one with that >> host has more traffic and is fine. >> >> So far this indicator seems to be no help to me. > > Keep in mind that the overload state might not be only about traffic capacity. > Like this page states, there other factors including CPU and memory pressure. > > https://support.torproject.org/relay-operators/relay-bridge-overloaded/ > > We are in a continuous process of making it better with feedback from the > relay community. It is a hard problem because so many things can change or > influence things. And different OSes also makes it challenging. > > Another thing here to remember, the overload state will be set for 72 hours > even if a SINGLE overload event occurred. > > For more details: > https://lists.torproject.org/pipermail/tor-relays/2021-September/019844.html > > (FYI, we are in the process of adding this information in the support page ^). We have now updated the support article at: https://support.torproject.org/relay-operators/relay-bridge-overloaded/ We have tried to clarify how and why the overloaded state is triggered. I hope this can help operators understand better why their relays can be found in this state and how a normal state can be recovered. Please do let us know what you think. Cheers, -hiro > > If you can't find sticking out, that is OK, you can move on and see if it > continues to stick. If so, maybe its worth digging more and when 0.4.7 will be > stable, you'll be able to enable the MetricsPort (man tor) to get into the > rabbit hole a bit deeper. > > Cheers! > David > > > ___ > 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] Overloaded state indicator on relay-search
On 9/28/21 8:40 PM, Toralf Förster wrote: > On 9/23/21 3:39 PM, Silvia/Hiro wrote: >> Let us known how you find this new feature. > It would be nice if even the search form would have that feature too. > Currently here all is green: > https://metrics.torproject.org/rs.html#search/zwiebeltoralf > wherease the details of each of the 2 relays shows the overload indicator. > Yes, good catch. I have just deployed a few minor fixes, among which the overloaded indicator in the search form. I had the intention to announce it tomorrow together with a few updates to the support article following the email threads on the list, but since you mentioned I though you should know already :)) Cheers, -hiro > -- > Toralf > ___ > 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] Overloaded state indicator on relay-search
Ofc I meant you can reply off list. On 9/27/21 11:16 AM, Silvia/Hiro wrote: > Gary, > > Replying off list. > Can I know which one is your relay? > We don't do user-agent detection. > > Cheers, > -hiro > > On 9/26/21 4:27 AM, Gary C. New via tor-relays wrote: >> Hiro, >> Presently, I'm seeing a similar issue. On my laptop, I'm observing an >> overloaded status for my relay. However, the same relay shows a green status >> on my phone. >> Do you do any user-agent detection? >> I'm still interested in those magic numbers, which determine whether a relay >> has reached an overloaded state. >> Thank You. >> Respectfully, >> >> Gary >> >> On Saturday, September 25, 2021, 7:11:31 AM PDT, Silvia/Hiro >> wrote: >> >> Hi, >> I went back in history and tried to find out whenever your node >> FriendlyExit1 was overloaded. I couldn't find the exact descriptor. >> >> One thing I can think of is that on the 22nd when I deployed this I >> noticed a few typos in the code and had to make a second release. Maybe >> something was cached for a while and you what you were accessing from >> mobile was the buggy page. >> >> If it happens again there are two buttons at the end of the page where >> you can see the latest server and extra-info descriptors. If you >> download the server one you would be able to verify that there is a >> "overload-general" field in there. If there isn't we have a bug :). >> >> Please let me know if this happens again. >> >> Cheers, >> -hiro >> >> On 9/24/21 2:39 PM, friendlyexitnode via tor-relays wrote: >>> Hey hiro, thanks! >>> >>> I've also attached some screenshots too if it helps (sorry, I should have >>> done that before). I had first noticed this around 3:45 PM CST on September >>> 23. >>> >>> - The Friendly Exit Node Family >>> >>> Sent with ProtonMail Secure Email. >>> >>> ‐‐‐ Original Message ‐‐‐ >>> >>> On Friday, September 24th, 2021 at 4:47 AM, Silvia/Hiro >>> wrote: >>> >>>> On 9/23/21 10:54 PM, friendlyexitnode via tor-relays wrote: >>>> >>>>> This looks like an awesome feature! I super appreciate it. >>>>> >>>>> Random question though (and I'm the first to admit I may be doing >>>>> something wrong), I notice that on Mobile it says my relays are >>>>> overloaded however when I view it on a normal computer I don't get the >>>>> overloaded indicator. I've tried refreshing multiple times but getting >>>>> the same results. Is anyone seeing the same thing? >>>> >>>> Hi, >>>> >>>> could you let me know when you accessed the page via mobile approximately? >>>> >>>> I'll try to check if any of your relays were overloaded in the past. >>>> >>>> When a node is overloaded the state is kept for 72 hours. >>>> >>>> Cheers, >>>> >>>> -hiro >>>> >>>>> Family Members: >>>>> >>>>> F01E382DA524A57F2BFB3C4FF270A23D5CD3311D >>>>> >>>>> 6231A1370700DD03046A85D953D35CAB5C21 >>>>> >>>>> F9A28AB71D7E4E446308641A556EA53BA55FCB50 >>>>> >>>>> 23F74D581DE92AC59D3527DE4D448E036139D81E >>>>> >>>>> A00E900534DFF76371064C03714753EAF8B88820 >>>>> >>>>> C232D8EE677E6BDF5CFFDDCAC4E2B1682DCE7AE5 >>>>> >>>>> - The Friendly Exit Node Family >>>>> >>>>> Sent with ProtonMail Secure Email. >>>>> >>>>> ‐‐‐ Original Message ‐‐‐ >>>>> >>>>> On Thursday, September 23rd, 2021 at 8:39 AM, Silvia/Hiro >>>>> h...@torproject.org wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> One of our goals with our current performance work is to reduce the >>>>>> >>>>>> overload of relays in the network. The implementation of proposal 328[1] >>>>>> >>>>>> a while back made different overload indicators available to relay >>>>>> >>>>>> operators and since a couple of weeks ago those can be tracked via >>>>>> >>>>>> Onionoo[2] as well. >>>>>> >>>>>> As we know that a lot of our
Re: [tor-relays] Overloaded state indicator on relay-search
Gary, Replying off list. Can I know which one is your relay? We don't do user-agent detection. Cheers, -hiro On 9/26/21 4:27 AM, Gary C. New via tor-relays wrote: > Hiro, > Presently, I'm seeing a similar issue. On my laptop, I'm observing an > overloaded status for my relay. However, the same relay shows a green status > on my phone. > Do you do any user-agent detection? > I'm still interested in those magic numbers, which determine whether a relay > has reached an overloaded state. > Thank You. > Respectfully, > > Gary > > On Saturday, September 25, 2021, 7:11:31 AM PDT, Silvia/Hiro > wrote: > > Hi, > I went back in history and tried to find out whenever your node > FriendlyExit1 was overloaded. I couldn't find the exact descriptor. > > One thing I can think of is that on the 22nd when I deployed this I > noticed a few typos in the code and had to make a second release. Maybe > something was cached for a while and you what you were accessing from > mobile was the buggy page. > > If it happens again there are two buttons at the end of the page where > you can see the latest server and extra-info descriptors. If you > download the server one you would be able to verify that there is a > "overload-general" field in there. If there isn't we have a bug :). > > Please let me know if this happens again. > > Cheers, > -hiro > > On 9/24/21 2:39 PM, friendlyexitnode via tor-relays wrote: >> Hey hiro, thanks! >> >> I've also attached some screenshots too if it helps (sorry, I should have >> done that before). I had first noticed this around 3:45 PM CST on September >> 23. >> >> - The Friendly Exit Node Family >> >> Sent with ProtonMail Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> >> On Friday, September 24th, 2021 at 4:47 AM, Silvia/Hiro >> wrote: >> >>> On 9/23/21 10:54 PM, friendlyexitnode via tor-relays wrote: >>> >>>> This looks like an awesome feature! I super appreciate it. >>>> >>>> Random question though (and I'm the first to admit I may be doing >>>> something wrong), I notice that on Mobile it says my relays are overloaded >>>> however when I view it on a normal computer I don't get the overloaded >>>> indicator. I've tried refreshing multiple times but getting the same >>>> results. Is anyone seeing the same thing? >>> >>> Hi, >>> >>> could you let me know when you accessed the page via mobile approximately? >>> >>> I'll try to check if any of your relays were overloaded in the past. >>> >>> When a node is overloaded the state is kept for 72 hours. >>> >>> Cheers, >>> >>> -hiro >>> >>>> Family Members: >>>> >>>> F01E382DA524A57F2BFB3C4FF270A23D5CD3311D >>>> >>>> 6231A1370700DD03046A85D953D35CAB5C21 >>>> >>>> F9A28AB71D7E4E446308641A556EA53BA55FCB50 >>>> >>>> 23F74D581DE92AC59D3527DE4D448E036139D81E >>>> >>>> A00E900534DFF76371064C03714753EAF8B88820 >>>> >>>> C232D8EE677E6BDF5CFFDDCAC4E2B1682DCE7AE5 >>>> >>>> - The Friendly Exit Node Family >>>> >>>> Sent with ProtonMail Secure Email. >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> >>>> On Thursday, September 23rd, 2021 at 8:39 AM, Silvia/Hiro >>>> h...@torproject.org wrote: >>>> >>>>> Hello all, >>>>> >>>>> One of our goals with our current performance work is to reduce the >>>>> >>>>> overload of relays in the network. The implementation of proposal 328[1] >>>>> >>>>> a while back made different overload indicators available to relay >>>>> >>>>> operators and since a couple of weeks ago those can be tracked via >>>>> >>>>> Onionoo[2] as well. >>>>> >>>>> As we know that a lot of our relay operators use relay search to check >>>>> >>>>> for the health of their relays, we have launched a new feature there, >>>>> >>>>> too, to help them know when their relays are overloaded. >>>>> >>>>> When a relay is in the overloaded state we show an amber dot next to the >>>>> >>>>> relay nickname. >>>>> >>>>> Currently we are counting between 50 and 80 overloaded relays and >>>>&g
Re: [tor-relays] Overloaded state indicator on relay-search
Hi, I went back in history and tried to find out whenever your node FriendlyExit1 was overloaded. I couldn't find the exact descriptor. One thing I can think of is that on the 22nd when I deployed this I noticed a few typos in the code and had to make a second release. Maybe something was cached for a while and you what you were accessing from mobile was the buggy page. If it happens again there are two buttons at the end of the page where you can see the latest server and extra-info descriptors. If you download the server one you would be able to verify that there is a "overload-general" field in there. If there isn't we have a bug :). Please let me know if this happens again. Cheers, -hiro On 9/24/21 2:39 PM, friendlyexitnode via tor-relays wrote: > Hey hiro, thanks! > > I've also attached some screenshots too if it helps (sorry, I should have > done that before). I had first noticed this around 3:45 PM CST on September > 23. > > - The Friendly Exit Node Family > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, September 24th, 2021 at 4:47 AM, Silvia/Hiro > wrote: > >> On 9/23/21 10:54 PM, friendlyexitnode via tor-relays wrote: >> >>> This looks like an awesome feature! I super appreciate it. >>> >>> Random question though (and I'm the first to admit I may be doing something >>> wrong), I notice that on Mobile it says my relays are overloaded however >>> when I view it on a normal computer I don't get the overloaded indicator. >>> I've tried refreshing multiple times but getting the same results. Is >>> anyone seeing the same thing? >> >> Hi, >> >> could you let me know when you accessed the page via mobile approximately? >> >> I'll try to check if any of your relays were overloaded in the past. >> >> When a node is overloaded the state is kept for 72 hours. >> >> Cheers, >> >> -hiro >> >>> Family Members: >>> >>> F01E382DA524A57F2BFB3C4FF270A23D5CD3311D >>> >>> 6231A1370700DD03046A85D953D35CAB5C21 >>> >>> F9A28AB71D7E4E446308641A556EA53BA55FCB50 >>> >>> 23F74D581DE92AC59D3527DE4D448E036139D81E >>> >>> A00E900534DFF76371064C03714753EAF8B88820 >>> >>> C232D8EE677E6BDF5CFFDDCAC4E2B1682DCE7AE5 >>> >>> - The Friendly Exit Node Family >>> >>> Sent with ProtonMail Secure Email. >>> >>> ‐‐‐ Original Message ‐‐‐ >>> >>> On Thursday, September 23rd, 2021 at 8:39 AM, Silvia/Hiro >>> h...@torproject.org wrote: >>> >>>> Hello all, >>>> >>>> One of our goals with our current performance work is to reduce the >>>> >>>> overload of relays in the network. The implementation of proposal 328[1] >>>> >>>> a while back made different overload indicators available to relay >>>> >>>> operators and since a couple of weeks ago those can be tracked via >>>> >>>> Onionoo[2] as well. >>>> >>>> As we know that a lot of our relay operators use relay search to check >>>> >>>> for the health of their relays, we have launched a new feature there, >>>> >>>> too, to help them know when their relays are overloaded. >>>> >>>> When a relay is in the overloaded state we show an amber dot next to the >>>> >>>> relay nickname. >>>> >>>> Currently we are counting between 50 and 80 overloaded relays and >>>> >>>> between 10 and 20 overloaded bridges. >>>> >>>> The overloaded state is reached when one or many of the possible load >>>> >>>> metrics have been triggered. When this happens we show it for 72 hours >>>> >>>> after the relay has recovered [3]. Note, though, that not all of the >>>> >>>> exposed overload metrics are triggering the overload indicator on relay >>>> >>>> search yet. >>>> >>>> If you noticed your relay is overloaded, please check the following >>>> >>>> support article to find out how you can recover to a "normal" state: >>>> >>>> https://support.torproject.org/relay-operators/relay-bridge-overloaded/ >>>> >>>> Let us known how you find this new feature. >>>> >>>> Cheers, >>>> >>>> -hiro >>>> >>>> [1] >>>> >>>> https://gitweb.torproject.org/torspec.git/tree/proposals/328-relay-overload-report.md >>>> >>>> [2] >>>> >>>> https://lists.torproject.org/pipermail/tor-project/2021-August/003168.html >>>> >>>> [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n637 >>>> >>>> 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Overloaded state indicator on relay-search
On 9/23/21 10:54 PM, friendlyexitnode via tor-relays wrote: > This looks like an awesome feature! I super appreciate it. > > Random question though (and I'm the first to admit I may be doing something > wrong), I notice that on Mobile it says my relays are overloaded however when > I view it on a normal computer I don't get the overloaded indicator. I've > tried refreshing multiple times but getting the same results. Is anyone > seeing the same thing? Hi, could you let me know when you accessed the page via mobile approximately? I'll try to check if any of your relays were overloaded in the past. When a node is overloaded the state is kept for 72 hours. Cheers, -hiro > > Family Members: > F01E382DA524A57F2BFB3C4FF270A23D5CD3311D > 6231A1370700DD03046A85D953D35CAB5C21 > F9A28AB71D7E4E446308641A556EA53BA55FCB50 > 23F74D581DE92AC59D3527DE4D448E036139D81E > A00E900534DFF76371064C03714753EAF8B88820 > C232D8EE677E6BDF5CFFDDCAC4E2B1682DCE7AE5 > > - The Friendly Exit Node Family > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, September 23rd, 2021 at 8:39 AM, Silvia/Hiro > wrote: > >> Hello all, >> >> One of our goals with our current performance work is to reduce the >> >> overload of relays in the network. The implementation of proposal 328[1] >> >> a while back made different overload indicators available to relay >> >> operators and since a couple of weeks ago those can be tracked via >> >> Onionoo[2] as well. >> >> As we know that a lot of our relay operators use relay search to check >> >> for the health of their relays, we have launched a new feature there, >> >> too, to help them know when their relays are overloaded. >> >> When a relay is in the overloaded state we show an amber dot next to the >> >> relay nickname. >> >> Currently we are counting between 50 and 80 overloaded relays and >> >> between 10 and 20 overloaded bridges. >> >> The overloaded state is reached when one or many of the possible load >> >> metrics have been triggered. When this happens we show it for 72 hours >> >> after the relay has recovered [3]. Note, though, that not all of the >> >> exposed overload metrics are triggering the overload indicator on relay >> >> search yet. >> >> If you noticed your relay is overloaded, please check the following >> >> support article to find out how you can recover to a "normal" state: >> >> https://support.torproject.org/relay-operators/relay-bridge-overloaded/ >> >> Let us known how you find this new feature. >> >> Cheers, >> >> -hiro >> >> [1] >> >> https://gitweb.torproject.org/torspec.git/tree/proposals/328-relay-overload-report.md >> >> [2] >> >> https://lists.torproject.org/pipermail/tor-project/2021-August/003168.html >> >> [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n637 >> >> 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] Overloaded state indicator on relay-search
Hello all, One of our goals with our current performance work is to reduce the overload of relays in the network. The implementation of proposal 328[1] a while back made different overload indicators available to relay operators and since a couple of weeks ago those can be tracked via Onionoo[2] as well. As we know that a lot of our relay operators use relay search to check for the health of their relays, we have launched a new feature there, too, to help them know when their relays are overloaded. When a relay is in the overloaded state we show an amber dot next to the relay nickname. Currently we are counting between 50 and 80 overloaded relays and between 10 and 20 overloaded bridges. The overloaded state is reached when one or many of the possible load metrics have been triggered. When this happens we show it for 72 hours after the relay has recovered [3]. Note, though, that not all of the exposed overload metrics are triggering the overload indicator on relay search yet. If you noticed your relay is overloaded, please check the following support article to find out how you can recover to a "normal" state: https://support.torproject.org/relay-operators/relay-bridge-overloaded/ Let us known how you find this new feature. Cheers, -hiro [1] https://gitweb.torproject.org/torspec.git/tree/proposals/328-relay-overload-report.md [2] https://lists.torproject.org/pipermail/tor-project/2021-August/003168.html [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n637 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
