tor-relays February 2024

tor-relays@lists.torproject.org

26 participants
18 discussions

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

Tor is not upgrading via apt from deb.torproject.org
by s7r 23 Mar '24

23 Mar '24

Hello all, I have recently found something interesting on my relays. On all relays and clients actually. As always I am using Debian and apt to get Tor from deb.torproject.org tor-nightly-main-bullseye main (for example). I also have the keyring installed, proper key and everything. Currently I am on: Tor version 0.4.9.0-alpha-dev. This build of Tor is covered by the GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html) Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1w, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc. Tor compiled with GCC version 10.2.1 Since October 2023. If I manually check out deb.torproject.org with my browser I see there is another package released in February 2024, except it notes as the same version 4.9.0-alpha-dev but it has a different timestamp. $ apt update reports no errors, looks like is working fine, but it doesn't notify there's a newer version and does not apply any updates to Tor. This happens only to Tor package from nightly, rest of packages from debian.org deb are updated as usual. So, anyone else experienced this? Do I need to configure apt in a different way than we used to do? I maintain this style of setup for Tor since Debian 7 :-), any changes needed? Thank you! -s7r

5 8

Problem with relay and ovh??
by Keifer Bly 07 Mar '24

07 Mar '24

Hi, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… Goes offline at sporadic times. Upon checking the tor log file, there does not appear to be anything written causing tor to crash: Feb 18 00:36:34.000 [notice] Tor 0.4.8.10 opening new log file. Feb 18 00:36:34.630 [notice] We compiled with OpenSSL 101010ef: OpenSSL 1.1.1n 15 Mar 2022 and we are running with OpenSSL 101010ef: 1.1.1n. These two versions should be binary compatible. Feb 18 00:36:34.634 [notice] Tor 0.4.8.10 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Feb 18 00:36:34.634 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Feb 18 00:36:34.636 [notice] Read configuration file "/etc/tor/torrc". Feb 18 00:36:34.637 [notice] Based on detected system memory, MaxMemInQueues is set to 1462 MB. You can override this by setting MaxMemInQueues by hand. Feb 18 00:36:34.640 [notice] Opening OR listener on 0.0.0.0:9001 Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on 0.0.0.0:9001 Feb 18 00:36:34.640 [notice] Opening OR listener on [::]:9001 Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on [::]:9001 Feb 18 00:36:34.640 [notice] Opening Directory listener on 0.0.0.0:9030 Feb 18 00:36:34.640 [notice] Opened Directory listener connection (ready) on 0.0.0.0:9030 Feb 18 00:36:35.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Feb 18 00:36:35.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. Feb 18 00:36:35.000 [notice] Your Tor server's identity key fingerprint is 'udeserveprivacy 79E3B585803DE805CCBC00C1EF36B1E74372861D' Feb 18 00:36:35.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'udeserveprivacy b7n+DkH5IsJHJexEqilhQ5tC0LRd9Td888RZpYkxEvc' Feb 18 00:36:35.000 [notice] Bootstrapped 0% (starting): Starting Feb 18 00:36:49.000 [notice] Starting with guard context "default" Feb 18 00:36:50.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. Feb 18 00:36:50.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Feb 18 00:36:50.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Unless the old file is being overwritten when tor restarts. But is there a known problem with OVH that causes this? Thanks. Oddly there is no definite time when this happens, sometimes the relay operates no problem for weeks on end and then it happens, other times it only makes it a day or two. --Keifer

3 4

Next Tor Relay Operator Meetup - March 2nd, 2024 @ 19.00 UTC
by gus 05 Mar '24

05 Mar '24

Hello Tor Relay operators, Please save the date! The next Tor Relay Operator Meetup will happen on Saturday, March 2nd at 2024 at 19.00 UTC. We're still working on the agenda for this meetup, however feel free to add your topics directly to the ticket or just reply to the mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/86 Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: March 2nd, 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. best, Gus -- The Tor Project Community Team Lead

1 3

Worse throughput with 0.4.8.x, on a slow CPU
by Roman Mamedov 04 Mar '24

04 Mar '24

Hello, Ater upgrading from Tor 0.4.7.13 to 0.4.8.9, I get a much worse bandwidth numbers. The CPU is Atom C2338 with two cores at 1.75 Ghz. Multiple Tor instances are running to take advantage of both cores. 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? Here's how it looks for a few days on 0.4.8 then a roll-back: ------------------------+-------------+-------------+--------------- today 461.94 GiB | 470.84 GiB | 932.78 GiB | 153.98 Mbit/s ######################################## 12/12/23 462.81 GiB | 475.67 GiB | 938.48 GiB | 91.12 Mbit/s ####################### 12/11/23 434.72 GiB | 443.08 GiB | 877.80 GiB | 85.23 Mbit/s ###################### 12/10/23 446.13 GiB | 459.56 GiB | 905.70 GiB | 87.93 Mbit/s ####################### 12/09/23 464.79 GiB | 473.17 GiB | 937.96 GiB | 91.07 Mbit/s ####################### 12/08/23 454.67 GiB | 463.48 GiB | 918.16 GiB | 89.14 Mbit/s ####################### 12/07/23 463.82 GiB | 472.84 GiB | 936.65 GiB | 90.94 Mbit/s ####################### 12/06/23 670.01 GiB | 680.55 GiB | 1.32 TiB | 131.13 Mbit/s ################################## 12/05/23 808.50 GiB | 817.32 GiB | 1.59 TiB | 157.85 Mbit/s ######################################### 12/04/23 854.09 GiB | 866.43 GiB | 1.68 TiB | 167.05 Mbit/s ########################################### 12/03/23 782.20 GiB | 799.00 GiB | 1.54 TiB | 153.52 Mbit/s ######################################## 12/02/23 805.18 GiB | 817.91 GiB | 1.59 TiB | 157.59 Mbit/s ######################################### 12/01/23 733.80 GiB | 745.35 GiB | 1.44 TiB | 143.61 Mbit/s ##################################### 11/30/23 742.48 GiB | 756.56 GiB | 1.46 TiB | 145.54 Mbit/s ##################################### 11/29/23 657.90 GiB | 673.66 GiB | 1.30 TiB | 129.28 Mbit/s ################################# In general, are there any tweaks to reduce relay CPU usage on a slow processor? I did seemingly most of what is possible, ethtool, iptables, sysctl, etc. How long before the Rust-based Tor will be ready for use on relays? -- With respect, Roman

4 5

Re: [tor-relays] bridges for Lox
by Holonet 04 Mar '24

04 Mar '24

> On 27 Feb 2024, at 15:39, boldsuck <lists(a)for-privacy.net> 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.

4 3

bridges for Lox
by meskio 28 Feb '24

28 Feb '24

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.

5 13

Re: [tor-relays] tor-relays Digest, Vol 157, Issue 19
by badgerfighter 27 Feb '24

27 Feb '24

+1 incoming. On Tuesday, February 27th, 2024 at 04:17, tor-relays-request(a)lists.torproject.org <tor-relays-request(a)lists.torproject.org> wrote: > > > Send tor-relays mailing list submissions to > tor-relays(a)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-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)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 meskio(a)torproject.org > > To: tor-relays tor-relays(a)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. >

1 0

Tor Relay Automatic PMTU Testing
by pasture_clubbed242＠simplelogin.com 22 Feb '24

22 Feb '24

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

3 3

VPS w/FDE suggestions?
by MRob 22 Feb '24

22 Feb '24

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)

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays February 2024