- tor-relays - lists.torproject.org

Relay bandwidth issue
by kricklen＠tutanota.com 07 Jun '24

07 Jun '24

Hello everyone, i got a local relay running with v0.4.8.11 and the following configuration: ... RelayBandwidthRate 4 MBytes RelayBandwidthBurst 7 MBytes ExitPolicy reject *:* ExitRelay 0 SocksPort 0 About a month ago, the relay started to behave differently than it used to: A few hours after each restart, it didn't respect the bandwidth limits anymore, meaning it took what it could get. After a while my isp interrupts my connection, i guess because of exhaustive traffic or connections being established, not sure. This leads to the following loop: 1. The relay notices it's ip changed and starts over 2. It consumes max bandwidth after a while 3. The isp disconnects 4. Start at 1, until after enough loops the relay is broken and doesn't connect anymore I'm not sure what caused the different behaviour, i don't have a close look on when my relay gets an update. The issue is severe for me though, so any help in fixing the bandwidth limit again would be really appreciated. -- Sent with Tuta; enjoy secure & ad-free emails: https://tuta.com

2 1

Onion Services operators please enable tor PoW defense
by gus 06 Jun '24

06 Jun '24

Hi, As some of you might have noticed, we have a high load situation on the network for a couple of weeks now affecting in particular onion services (but not only them).[1] We recommend Onion Services operators to enable our Proof of Work (PoW) defense[2][3] and finetune their torrc[4]. If you're running onion services with onionbalance, though, PoW is currently not supported[5], but we're interested in hearing from you if this is a feature that we should prioritize. Thanks, Gus ps: this advice does not apply to relay operators, only to onion services operators. [1] https://status.torproject.org/issues/2024-05-14-network-performance-issues/ [2] https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-ser… [3] https://community.torproject.org/onion-services/ecosystem/technology/pow/ [4] https://community.torproject.org/onion-services/advanced/dos/ [5] https://community.torproject.org/onion-services/ecosystem/technology/pow/#i… -- The Tor Project Community Team Lead

3 3

Directory authorities not giving weight to a relay
by smoothop＠tutanota.de 03 Jun '24

03 Jun '24

Greetings everyone! Almost three months ago I have set up my first node. Everything seemed to be going great at first and as documented in the tor lifecycle blog post. A few days after being set up the weight drastically dropped to around twenty. This seemed a bit odd since that same blog post doesn't mention anything about weight dropping so much, but it does about bandwidth, ao I just shrugged it off and assumed it was normal. Anyway, fast forward to today, and the weight hasn't really gotten above two hundred, it has been a month and a half I think since the weight drop, and it has been stale at a weight of between one hundred eighty and two hundred. I can't put my finger on what is exactly the problem, the relay currently has six flags: Fast, HSDir, Running, Stable, V2Dir and Valid. Shortly after the drop I have even seen the Guard flag for like a day. The server has capacity and is dedicated solely to being a relay, and the ISP is in the good providers list. The fingerprint of the node is ACC72E6D0FA76168AE1BA7F26996D191FEA7C9D8. Maybe someone in this list can give me a hand and point me in the right direction. Thank you in advance!

4 3

Tor relays Bazinga and JPsi2 to be shut down
by Random Tor Node Operator 03 Jun '24

03 Jun '24

Hi all, I have been operating the relays - Bazinga B198C0B4B8C551F174FBB841A172616E3DB3124D - JPsi2 F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 for about 10 years. The hosting provider stops providing their current service and their successor services are not Tor-friendly anymore. Hence, these relays will be shut down by June 2 2024. My third relay - SafeAndEffective A508096AA0C899F4E6ECD1D9C35037B89008BCBA is unaffected.

2 1

Warn_TorBTCMoon
by tor 27 May '24

27 May '24

Nickname TorBTCMoon ContactInfo torsafe777(a)gmail.com Your computer is too slow to handle this many circuit creation requests! Please coconsider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit CPU 100% How to fix?

2 1

We need to talk about the latest DDoS affecting the Tor network
by koizoi 25 May '24

25 May '24

For several weeks now, users have been complaining (see https://www.reddit.com/r/TOR/comments/1cnmsdz/tor_extremely_slow_lately/, https://forum.torproject.org/t/is-there-currently-a-major-ddos-affecting-th…, etc) about degraded performance (slow speeds, timeouts) when using Tor, both to access v3 onion sites and clearnet websites. In my personal experience, most v3 onion services are responding so slowly that they're completely unusable. it turns out that's it not just people's imaginations, looking at charts on metrics.torproject.org, it can be seen that the time to complete a 5MiB request over Tor has increased substantially (https://ibb.co/tp1CHdh) All of this is very reminiscent of the large scale DDoS that affected Tor relay nodes in 2022-2023. Tor relay operators have reported "attacks" on their relays, but there haven't been many details about what kind of attacks are taking place, other than some people saying that they have been TCP SYN flooded. But (to me, anyway) SYN flooding doesn't really make a lot of sense as there are so many Tor relay nodes that would need to be attacked, (and misconfigured to allow a SYN flood attack to work), and even if it were a SYN flood, that would cause different behavior than what users have been seeing (preventing connections to the Tor network rather than slowing them down). I understand that DDoS attacks on the Tor network might be kind of a touchy subject, but it would be good if we could get some information from the project leadership as to what's going on, what is being done about it, and what Tor relay operators can do to help prevent attacks like these from happening. Thanks Sent with [Proton Mail](https://proton.me/) secure email.

2 1

Next Tor relay operators meetup - May 11, 2024 at 19 UTC
by gus 14 May '24

14 May '24

Hi, Please save the date: the next Tor Relay Operator will happen Saturday, May 11 at 19UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to this ticket or just reply to the mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/92 Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: May 11, 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. I'll send soon the last meetup notes to the list. Gus -- The Tor Project Community Team Lead

2 3

disable conflux on exit relay?
by applied-privacy.net 13 May '24

13 May '24

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

4 7

Updating tor issue
by Keifer Bly 13 May '24

13 May '24

https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… Hi, so for my relay at the address above, when trying to update tor, suddenly getting the "updating from such a respiratory can't be done securly" message. Odd as this just suddenly started happening. Here is my sources file. What is the correct format for adding tor as a trusted source? Thanks. deb-src http://deb.debian.org/debian buster main ## Major bug fix updates produced after the final release of the ## distribution. deb http://security.debian.org/ buster/updates main deb-src http://security.debian.org/ buster/updates main ## Uncomment the following two lines to add software from the 'backports' ## repository. ## ## N.B. software from this repository may not have been tested as ## extensively as that contained in the main release, although it includes ## newer versions of some applications which may provide useful features. deb http://deb.debian.org/debian buster-backports main deb-src http://deb.debian.org/debian buster-backports main deb [trusted=yes] https://deb.torproject.org/torproject.org buster main --Keifer

6 13

response to zimmer family hitting max descriptor size
by code9n＠pm.me 07 May '24

07 May '24

Hi, re. # Questions & Answers * Q: zimmer family hitting max descriptor size https://gitlab.torproject.org/tpo/core/tor/-/issues/40837 Any news on a possible solution to this ongoing issue? tl;dr: more powerful relays rather than large numbers of them. *Please note I have very little idea what I'm talking about here and there's probably something I don't know about or just don't understand. If a family has a very large number of exit relays but the capacity of each one is not that great couldn't they just spend the same money on making existing relays more powerful rather than having more of them? If we're using VPSs then the limits applicable to single cores don't seem to apply the way they do to physical servers. I run a single non-exit relay but I get more traffic through it by having more RAM and multiple vCPUs. The VPS seems to act like it has one large, powerful core rather than the 5 smaller one's it 'actually' has. So if 'descriptors' refer to the number of relays not their capacity wouldn't this work? Side note: to get more bang for your buck you can ask your VPS provider to swap some storage for more vCPUs, that's what I did and it certainly seems to allow me to run more traffic through my one relay. It doesn't need that much storage anyway. So you get the same amount of traffic through fewer, larger relays. cheers,

1 0