February 2023 - tor-relays - lists.torproject.org

recommended way to run 0.4.7 on armhf?
by ilf 25 Nov '23

25 Nov '23

What's the recommended way to run 0.4.7 on armhf? > The package repository [deb.torproject.org] does not offer 32-bit ARM > architecture (armhf) images (yet). https://support.torproject.org/apt/tor-deb-repo/ Debian has 0.4.7 in bullseye-backports. But Raspbian doesn't have bullseye-backports: http://raspbian.raspberrypi.org/raspbian/dists/ -- ilf If you upload your address book to "the cloud", I don't want to be in it.

3 6

PSA: Tor 0.4.5 reaches end of life (EOL) on 2023-02-15
by Georg Koppen 17 May '23

17 May '23

Hello! In case it affects you as you are still running your relay or bridge on Tor 0.4.5.x: the 0.4.5 series is going EOL on *2023-02-15* (roughly in 3 weeks from now). That's currently still 760 relays, which means roughly 7% of the advertised bandwidth of the network (and 387 bridges, which means roughly 9% of the advertised bridges bandwidth). Please make sure you have upgraded to the 0.4.7.x series by then. Supported releases in general can be found on the network team wiki.[1] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele…

6 8

inet_csk_bind_conflict
by Christopher Sheats 21 Mar '23

21 Mar '23

Hello tor-relays, We are using Ubuntu server currently for our exit relays. Occasionally, exit throughput will drop from ~4Gbps down to ~200Mbps and the only observable data point that we have is a significant increase in inet_csk_bind_conflict, as seen via 'perf top', where it will hit 85% [kernel] utilization. A while back we thought we solved with with two /etc/sysctl.conf settings: net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 However we are still experiencing this problem. Both of our (currently, two) relay servers suffer from the same problem, at the same time. They are AMD Epyc 7402P bare-metal servers each with 96GB RAM, each has 20 exit relays on them. This issue persists after upgrading to 0.4.7.11. Screenshots of perf top are shared here: https://digitalcourage.social/@EmeraldOnion/109440197076214023 Does anyone have experience troubleshooting and/or fixing this problem? Cheers, -- Christopher Sheats (yawnbox) Executive Director Emerald Onion Signal: +1 206.739.3390 Website: https://emeraldonion.org/ Mastodon: https://digitalcourage.social/@EmeraldOnion/

6 20

Next Tor Relay Operator Meetup - March 4, 2023 (19 UTC)
by gus 19 Mar '23

19 Mar '23

Hi, The next Tor Relay Operator Meetup will happen on March 4, 2023, at 19 UTC! We're still working on the agenda, feel free to add your topics and/or questions on the pad: https://pad.riseup.net/p/tor-relay-op-meetup-m4-keep onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… WHERE Room link: https://tor.meet.coop/gus-og0-x74-dzn Registration No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Please share with your friends, social media and other mailing lists! Gus -- The Tor Project Community Team Lead

6 7

Confusing bridge signs...
by Keifer Bly 18 Mar '23

18 Mar '23

Hi, So my bridge at https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… says it has “none “, though the torrc file has it set to be distributed publicly. I'm wondering why the bridge would say that, when it obviously is being used as it's apparently blocked in Russia? I have not personally given the bridge to anyone. Thanks. --Keifer

5 25

Storing ed25519_master_id_secret_key[_encrypted] on a smartcard?
by telekobold 04 Mar '23

04 Mar '23

Dear fellow relay operators, currently, I'm operating a Tor relay (Middle/Guard) and a Tor Bridge. Offline keys [1],[2] are a good way to secure a Tor relay, but I'm wondering if there is a standard way or something like a hacking guide how to store your ed25519_master_id_secret_key[_encrypted] on a smartcard or hardware token like a Nitrokey or Yubikey? This would even be more secure than storing it on a "normal" USB device. Unfortunately I have not found much about this on the internet. Kind regards telekobold [1] https://support.torproject.org/relay-operators/offline-ed25519/ [2] https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/Offl…

1 1

Preferred range for ephemeral ports
by binarynoise 03 Mar '23

03 Mar '23

Hello everyone, I just set up a snowflake proxy on my pi at home. Unfortunately I can only forward 255 ports to my pi (at once, or is there a way to trick my Fritz!box into allowing more?). Which is the preferred range for -ephemeral-ports-range when it needs to be restricted to allow the most users to connect? Is 60000:60250 ok? Greetings binarynoise

2 1

removing tor versions from "recommended versions" before they reach EOL
by nusenu 01 Mar '23

01 Mar '23

Hi, the tor 0.4.5.x end of live versions are still on the recommended versions list: https://consensus-health.torproject.org/#recommendedversions > consensus client-versions 0.4.5.6, 0.4.5.7, 0.4.5.8, 0.4.5.9, 0.4.5.10, 0.4.5.11, 0.4.5.12, 0.4.5.14, 0.4.5.15, 0.4.5.16, 0.4.7.7, 0.4.7.8, 0.4.7.10, 0.4.7.11, 0.4.7.12, 0.4.7.13 > server-versions 0.4.5.6, 0.4.5.7, 0.4.5.8, 0.4.5.9, 0.4.5.10, 0.4.5.11, 0.4.5.12, 0.4.5.14, 0.4.5.15, 0.4.5.16, 0.4.7.7, 0.4.7.8, 0.4.7.10, 0.4.7.11, 0.4.7.12, 0.4.7.13 it would probably be better to stop recommending tor versions a month before they reach their eol date so relay operators get to see a log entry and have some time to react. kind regards, nusenu -- https://nusenu.github.io

2 1

relay configuration not allowing optimal performance
by Relayer 26 Feb '23

26 Feb '23

I'm running a tor relay on some older hardware that I didn't want to discard when I could still put it so good use. Some details of the box are: -- CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz -- RAM: 4GB -- ARCH: x86_64 -- HDD: 250GB -- OS: Ubuntu 22.04.1 I originally configured a single Tor instance IPv4 to run as a relay only (not as an exit, nor hosting a hidden service). I am also using the iptables rules from https://github.com/Enkidu-6/tor-ddos to minimize DDOS overhead (please advise if there are alternatives or additions to this). My original config seemed ok until I started seeing my CPU and RAM maxing out consistently so I throttled back with the following in my torrc: RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) MaxAdvertisedBandwidth 1 MB My RAM usage now is only about 50% or marginally less of my total available. Here's how the metrics look lately: https://metrics.torproject.org/rs.html#details/38939B45237BA84941C74836349C… As you can see, the throughput rated dropped in half (that's when the graph drops on 2023-02-09). However, the volume continued to decline. Additionally, I'm unclear why my Middle Probability and Consensus Weight have both dropped to near 0%. Are those, in fact, where I want them? I'm monitoring with nyx and see I get some traffic through with no apparent errors or warnings. I am NOT seeing the CPU spikes any longer but I don't think I'm giving the most with my hardware. Questions: 1.) Is my tor service now misconfigured and not utilizing my hardware as best it could? 2.) Should my Consensus Weight and/or Middle Probability be higher? 3.) Should I consider running two tor instances? Nyx log snippet: 07:59:32 [NOTICE] Heartbeat: DoS mitigation since startup: 7 circuits killed with too many cells, 591 circuits rejected, 2 marked addresses, 0 marked addresses for max queue, 0 same address concurrent │ connections rejected, 0 connections rejected, 0 single hop clients refused, 19166 INTRODUCE2 rejected. [1 duplicate hidden] │ 07:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 57982 v4 │ connections; initiated 116266 and received 356623 v5 connections. │ 07:59:32 [NOTICE] Circuit handshake stats since last time: 3/3 TAP, 44849/44849 NTor. [1 duplicate hidden] │ 07:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 194128391 (server descriptor fetch); 7140 (server descriptor upload); 17539422 (consensus network-status fetch); 1794 (authority cert │ fetch); 2111765 (microdescriptor fetch) │ 07:59:32 [NOTICE] Heartbeat: Tor's uptime is 10 days 23:58 hours, with 179 circuits open. I've sent 34.83 GB and received 35.63 GB. I've received 444762 connections on IPv4 and 0 on IPv6. I've made │ 254336 connections with IPv4 and 0 with IPv6. [1 duplicate hidden] │ 01:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 56651 v4 │ connections; initiated 114326 and received 347071 v5 connections. │ 01:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 189431170 (server descriptor fetch); 7140 (server descriptor upload); 17131743 (consensus network-status fetch); 1794 (authority cert │ fetch); 2068377 (microdescriptor fetch) Thanks. Relayer1974

2 1

Re: [tor-relays] Frantech (was Re: Confusing bridge signs)
by Jeff Teitel 26 Feb '23

26 Feb '23

On Fri, Feb 24, 2023 at 12:10 AM Marco wrote: > Yes, Frantech should actually be avoided. But in Miami there are few Tor > relays. A SLICE 512 for $2.00/m or $20.00/y is sufficient for a bridge. > https://buyvm.net/kvm-dedicated-server-slices/ Why should Frantech be avoided? Jeff Teitel

2 1