April 2022 - tor-relays - lists.torproject.org

How to reduce tor CPU load on a single bridge?
by David Fifield 19 Dec '22

19 Dec '22

The main Snowflake bridge (https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6…) is starting to become overloaded, because of a recent substantial increase in users. I think the host has sufficient CPU and memory headroom, and pluggable transport process (that receies WebSocket connections and forwards them to tor) is scaling across multiple cores. But the tor process is constantly using 100% of one CPU core, and I suspect that the tor process has become a bottleneck. Here are issues about a recent CPU upgrade on the bridge, and observations about the proportion of CPU used by different processes: https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… I have the impression that tor cannot use more than one CPU core—is that correct? If so, what can be done to permit a bridge to scale beyond 1×100% CPU? We can fairly easily scale the Snowflake-specific components around the tor process, but ultimately, a tor client process expects to connect to a bridge having a certain fingerprint, and that is the part I don't know how to easily scale. * Surely it's not possible to run multiple instances of tor with the same fingerprint? Or is it? Does the answer change if all instances are on the same IP address? If the OR ports are never used? * OnionBalance does not help with this, correct? * Are there configuration options we could set to increase parallelism? * Is migrating to a host with better single-core performance the only immediate option for scaling the tor process? Separate from the topic of scaling a single bridge, here is a past issue with thoughts on scaling beyond one bridge. it looks as though there are not ways to do it that do not require changes to the way tor handles its Bridge lines. https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… * Using multiple snowflake Bridge lines does not work well, despite that we could arrange to have the Snowflake proxy connect the user to the expected bridge, because tor will try to connect to all of them, not choose one at random. * Removing the fingerprint from the snowflake Bridge line in Tor Browser would permit the Snowflake proxies to round-robin clients over several bridges, but then the first hop would be unauthenticated (at the Tor layer). It would be nice if it were possible to specify a small set of permitted bridge fingerprints.

7 57

relayor v22.0.0-rc is released
by nusenu 03 Dec '22

03 Dec '22

Hi, relayor v22.0.0-rc is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes since relayor v21.2.0-rc: * MetricsPort support improvements: * generate nginx reverse server config for remote prometheus scraping on the relay (we do not install nginx) * generate htpasswd file for HTTP basic auth of MetricsPort on the relay * debian/ubuntu: support new alpha repos (branch name is no longer included in the repo name). * FreeBSD 12.3 is supported kind regards, nusenu -- https://nusenu.github.io

2 4

Does Tor work with Intel QAT acceleration
by Andreas Bollhalder 07 Jun '22

07 Jun '22

Hi all I have my first Tor relay up und running. It's currently installed on a little desktop computer with an Intel i5 9500T CPU. My Internet connection is 10Gb/s symetric. From this bandwidth, I would be able to spend a good part for supporting the Tor network. With that little machine, it seems that it would max out at somewhere at ~30 MBytes/s. For my definitive Tor relay hardware, I'm currently researching some options, which would be capable of handling Tor traffic at the rate of 200 to 300MBytes. Even it would be used nowadays, but who knows whats coming in the future and I hope this relay would last 5 years ore so. It looks to me, that with a normal CPU, it's impossible to reach my goal. But then I encountered, that Intel has the Quick Assist Technoloy (QAT) integrated in some of their products (ie. Atom C3xx8). This QAT can be used with OpenSSL as a hardware accelerator for encryption. There also exist dedicated PCIe cards with QAT (ie. Netgate CPIC-8955). Searching the Internet, I couldn't find any information if QAT would be helpful with Tor. But Tor uses the OpenSSL library and this can use the QAT acceleration. Is there anyone who has tried this und can share his expirience? Thanks in advance Andreas

4 6

[warn] Received a bad CERTS cell: Link certificate does not match TLS certificate
by Felix 07 Jun '22

07 Jun '22

Hi all I found a message in the logs: Apr 16 15:07:46.000 [warn] Received a bad CERTS cell: Link certificate does not match TLS certificate -- Cheers Felix

2 1

Loss of Guard and HS Dir flags
by Eddie 29 May '22

29 May '22

I currently run 3 relays, across different servers and today I noticed that one has now lost it's Guard and HS Dir flags. What's surprising is that this particular relay has the highest Bandwidth and Consensus Weight of all 3 and has not been restarted for over a month. The stats for all 3 can be found with: OhNoAnotherRelay I know that just running the relay is the important part and caring about what flags it has is a side issue, but I'm just interested in seeing why this has happened. Cheers.

4 7

comments, hints and tipps for an ansible role to deploy Tor bridges
by Toralf Förster 04 May '22

04 May '22

I do appreciate those for my attempt here: https://github.com/toralf/tor-relays TIA -- Toralf

2 1

Possible Connection Storm
by Eddie 26 Apr '22

26 Apr '22

Checking my relays after being away for a few days, noticed that one of them was showing as Overloaded, which I've never seen in over a year's running. Looking in the logs, it looks like there was a huge increase in connections, which has now settled down and I'm no longer showing as overloaded. Here's some relevant pieces: Apr 21 03:45:08.000 [notice] Heartbeat: Tor's uptime is 110 days 12:00 hours, wi th 6977 circuits open. I've sent 5236.04 GB and received 5121.19 GB. I've receiv ed 5232797 connections on IPv4 and 269395 on IPv6. I've made 2018765 connections with IPv4 and 580408 with IPv6. Apr 21 03:45:08.000 [notice] Circuit handshake stats since last time: 1901/1901 TAP, 244943/244943 NTor. Apr 21 07:04:49.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config opti on or choosing a more restricted exit policy. Apr 21 09:45:08.000 [notice] Heartbeat: Tor's uptime is 110 days 18:00 hours, wi th 47998 circuits open. I've sent 5263.73 GB and received 5148.85 GB. I've recei ved 5244063 connections on IPv4 and 270025 on IPv6. I've made 2021914 connection s with IPv4 and 581488 with IPv6. Apr 21 09:45:08.000 [notice] Circuit handshake stats since last time: 1609/1609 TAP, 6391488/6532508 NTor. Apr 21 15:45:08.000 [notice] Heartbeat: Tor's uptime is 111 days 0:00 hours, wit h 45439 circuits open. I've sent 5300.03 GB and received 5185.19 GB. I've receiv ed 5253283 connections on IPv4 and 270537 on IPv6. I've made 2024515 connections with IPv4 and 582464 with IPv6. Apr 21 15:45:08.000 [notice] Circuit handshake stats since last time: 467/467 TA P, 9937327/9984534 NTor. Is this anything I need to be concerned about, or is it just one of things that occasionally happens. Cheers.

2 1

Re: [tor-relays] Bridge Distribution Mechanism none
by Ross Camm 21 Apr '22

21 Apr '22

I have no error from Apparmor and I dont believe obfs4 proxy is the issue as I have obfs4 installed and confirmed running dpkg -l | grep obfs4 ii obfs4proxy 0.0.7-4 ps ax | grep obfs4 5501 ? Sl 0:01 /usr/bin/obfs4proxy netstat -nap | grep obfs4 tcp 0 0 X.X.X.X:12345 0.0.0.0:* LISTEN 5501/obfs4proxy Tor logs Apr 18 17:00:33 pi Tor[5497]: Registered server transport 'obfs4' at 'X.X.X.X:12345' torrc ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 X.X.X.X:12345 [ https://bridges.torproject.org/scan/ ]( https://bridges.torproject.org/scan/ ) also reports my ORPort is reachable via IPv4 and IPV6 Tor logs Apr 18 17:01:37 pi Tor[5497]: Self-testing indicates your ORPort [X:Y:Z::A]:993 is reachable from the outside. Excellent. Apr 18 17:01:37 pi Tor[5497]: Self-testing indicates your ORPort A.B.C.D:993 is reachable from the outside. Excellent. Publishing server descriptor. What am I missing ? Thanks again Ross > Probably because obfs4 is not installed or not running properly.> Check your logs for obfs4 errors, and for Apparmor error messages as well.> On Mon, Apr 18, 2022 at 09:07, Ross Camm <ross(a)whyza.net> wrote:> I have been up and running with my Tor Bridge for a number of months now, yet Tor Metrics reports that the Bridge Distribution Mechanism for my server is stuck on 'none'.>> Consequently I see no incoming connections to my Bridge.>> I have tried altering the following>> BridgeRelay 1>> PublishServerDescriptor bridge> BridgeDistribution moat>> with no success.>> The mechanism is always none....and I have left the changes for a week to see if Metrics updates to no avail.>> I have a static IPv4 address and functional IPv6 and have confirmed my ports are publicly accessible for both protocols>> Self-testing indicates your ORPort [XXXX:XXXX:XXXX::XXX]:993 is reachable from the outside. Excellent.> Self-testing indicates your ORPort XXX.XXX.XXX.XXX:993 is reachable from the outside. Excellent. Publishing server descriptor.>> I am running raspberry pi os buster which had an obsolete Tor version.>> I subsequently upgraded and stay up to date with the latest bullseye version via bullseye backports,>> Currently Tor 0.4.6.10-1~bpo10+1>> Any ideas of why my servers Bridge Distribution Mechanism is always reported and behaving as none ?>> Thanks in advance ;)>> Ross

2 1

Bridge Distribution Mechanism none
by Ross Camm 20 Apr '22

20 Apr '22

Thanks, that will no doubt be an issue Upgraded via debian backports dpkg -l | grep obfs4 ii obfs4proxy 0.0.13-1~bpo11+1 I will keep my eye on the bridge status page to see if the Bridge Mechanism changes as well as my incoming connections. Regards Ross Date: Tue, 19 Apr 2022 15:59:35 +0200 From: lists(a)for-privacy.net To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Bridge Distribution Mechanism none Message-ID: <2335525.61UdpqZOmS@w530> Content-Type: text/plain; charset="utf-8" On Tuesday, April 19, 2022 2:28:01 PM CEST 55578 via tor-relays wrote: > Probably because obfs4 is not installed or not running properly. Get the obfs4proxy package from backports. Outdated obfs bridges are rejected AFAIK. https://lists.torproject.org/pipermail/tor-relays/2022-March/020447.html -- ?_? Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

2 1

Bridges configuration
by onionize＠riseup.net 20 Apr '22

20 Apr '22

Hello, the Tor community. We already run relays and we have MyFamily configured. Now we want to start bridges. Should bridges have a separate family or we need to include them into relay family?

2 1