May 2024 - tor-relays - lists.torproject.org

Question on bridge hibernation
by Keifer Bly 18 Aug '24

18 Aug '24

Hi, So for my bridge at https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… Is set to hibernate once it reaches a certain traffic level (this is to prevent massive charges to my VPS). Now that is in hibernation, when will it start again, and how would this effect how it's distributed? Are bridges that are hibernating removed from relay search? Mew to hibernation, thanks. May 14 18:49:39.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 14 18:49:39.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. May 14 18:49:39.000 [notice] Bootstrapped 0% (starting): Starting May 14 18:49:47.000 [notice] Starting with guard context "default" May 14 18:49:47.000 [notice] Registered server transport 'obfs4' at '[::]:8081' May 14 18:49:48.000 [notice] Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted May 14 18:49:48.000 [notice] Going dormant. Blowing away remaining connections. May 14 18:49:48.000 [notice] Delaying directory fetches: We are hibernating or shutting down. --Keifer

3 2

Recent Tor versions not reloading config on / ignoring HUP kill signal.
by George Hartley 10 Aug '24

10 Aug '24

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

2 2

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