- tor-relays - lists.torproject.org

Tor bridges limit
by Me 25 Jul '22

25 Jul '22

Good day all. I am currently running two middle relays on my home network and was wondering if I can add any bridges to my existing set up. I am aware of the limit of two middle relays per ip address but do not see anything stating whether there was any such limit for bridges. I am also not clear on whether the bridges are recognized by the tor network in the same manner as Middle relays and whether the two unit limit applies to the total of devices connected. Thank you in advance for any … [View More]

2 1

Relay Overloaded and Dropping Onionskins
by bidulock_ringrose＠aleeas.com 21 Jul '22

21 Jul '22

Greetings! I hope this is the right list to be asking this, if it is not please forgive me. I am purposefully omitting some identifying information for privacy sake. I run 2 non-exit relays both with an advertised bandwidth of around 8 MiB/s each. I have noticed that they have been overloaded a lot lately. These relays have been bottlenecked at the 3-4 MiB/s mark ever since I put them online. Upon further investigation, when I curled the MetricsPort according to https://support.… [View More]

2 1

Bridges and Hs_vanguards
by dmz21 12 Jul '22

12 Jul '22

Dear readers, During the last week the bytes/second of my bridge dropped to 20% of its common usage over the past months, while the average number of connected clients stayed the same (according to metrics.torproject.org) I'm also seeing a dozen circuit connections with purpose Hs_vanguards in nyx recently, which are not familiar to me. Under-utilization of my bridge is not a problem to me, but maybe someone can tell me whether the two are related? Maybe it's an issue at my end or my hoster … [View More]

1 0

We're trying out guard-n-primary-guards-to-use=2
by Roger Dingledine 11 Jul '22

11 Jul '22

Hi folks, As part of the hackweek projects ( https://gitlab.torproject.org/tpo/community/hackweek/ ), some of us are thinking about simple tweaks we can do to tune the network to better handle this month's traffic overload. The long term answer is to try out proposal 327: https://gitweb.torproject.org/torspec.git/tree/proposals/327-pow-over-intro… because we think a lot of the overload has to do with people sending way too many intro cells to some onion services, and giving the onion … [View More]

4 5

Is ExoneraTor still alive?
by Christian Pietsch 07 Jul '22

07 Jul '22

Dear all, ExoneraTor is/was useful for showing law enforcement authorities that a given IP address acted as a Tor exit relay at a given day. Unfortunately, ExoneraTor seems to be offline. This page does not work at all, returning an HTTP 503 error immediately: https://exonerator.torproject.org/ This page returns the following error whenever I submit an IP address: https://metrics.torproject.org/exonerator.html | Server problem | | Unable to connect to the database. Please try again later. … [View More]

2 1

[Event] Tor relay operator meetup - June 25th @ 1900 UTC
by gus 27 Jun '22

27 Jun '22

Hello, The next Tor relay operator meetup will happen on Saturday, June 25 @ 1900 UTC. Where: BigBlueButton - https://tor.meet.coop/gus-og0-x74-dzn 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. Everyone is free to bring up additional questions or topics at the meeting itself. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

1 2

Relay "unmeasured" after update to 0.4.7.8
by Martin 27 Jun '22

27 Jun '22

Hi all! After updatering to the latest version, my relay consensus went down to 20 and was marked unmeasured. However it still serves a couple of thousand connections (capped at 10 MB/s) and all flags are still there, but when I try to use it to build a circuit manually it won't let me... Cheers

2 1

Metrics shows my relay down. But it's not.
by Eddie 25 Jun '22

25 Jun '22

The metrics is showing one of my relays (40D13096BBD11AF198CE61DEE4EAECCE5472F2E7) as down for around the last 3 hours. Logging in to it, I see everything running normally. This server has also lost a bunch of flags for no apparent reason, so I'm not sure if they're connected. Cheers.

2 1

FreeBSD 13.1: clock_gettime(CLOCK_MONOTONIC_FAST) ~ 50 % performance gain
by Andreas Kempe 22 Jun '22

22 Jun '22

Hello everyone, I was doing some profiling on my two relays running on FreeBSD 13.1 and noticed that they were spending a lot of time in clock_gettime() which prompted me to have a look at the implementation. Time implementation =================== The time implementation is abstracted in src/lib/time/compat_time.c where different mechanisms are used for different operating systems. On Linux CLOCK_MONOTONIC_COARSE is a clock that gives worse precision than CLOCK_MONOTONIC, but is faster and … [View More]the abstraction layer checks for its presense and provides more performat less precise time where applicable. On FreeBSD, there is also a fast monotonic time source available called CLOCK_MONOTONIC_FAST. In the header file src/lib/time/compat_time.h, a comment references this clock, but it is not used. I thought it might be worth a shot seeing what difference it would make if I enable the use of CLOCK_MONOTONIC_FAST on FreeBSD and on the VM where I run my two FreeBSD relays, the difference was stunning. I made did a quick patch simply replacing CLOCK_MONOTONIC_COARSE with CLOCK_MONOTONIC_FAST, see patches attached, compiled and tested. Tracing system calls to make sure the correct call was being used, which it was. Results ======= This lead to reducing the CPU usage of the patched relay by about 50 % compared to the unpatched relay. I was a bit shocked so I wrote a small benchmark program and ran it on my VM giving the following results: CLOCK_MONOTONIC: 4.776675 s CLOCK_MONOTONIC_FAST: 0.260002 s Showing that on my VM the performance of CLOCK_MONOTONIC_FAST is about 20 times better than CLOCK_MONOTONIC. I have tested on a few different systems and I think that the performance increase of CLOCK_MONOTONIC_FAST is thanks to commit 60b0ad10dd0fc7ff6892ecc7ba3458482fcc064c - "vdso: lower precision of vdso implementation of CLOCK_MONOTONIC_FAST and CLOCK_UPTIME_FAST" that was cherry-picked to 13.1. Try it yourself and report your results ======================================= If you want to benchmark your server to see whether switching clock could benefit you, you can compile and run my attached test program by doing user>clang -o bench.c -o bench user>./bench In case the program terminates too quickly or slowly for your liking, adjust const unsigned long iterations = 1000000; up or down to change the execution time. My supplied patches appear to work fine on my system, but aren't really upstream appropriate since a solution that works for both FreeBSD and Linux is needed. If you want to test them and you're building Tor from the ports tree, drop them in /usr/ports/security/tor/files and build and install. I'm very interested in seeing some performance data from other people to see whether I think it worth either pestering some Tor devs to have a look at this or putting in some effort myself to write an upstreamable patch. Thank you for reading! Cordially, Andreas Kempe [View Less]

3 4

From [tor-announce] Tor stable release 0.4.7.8 - Security Fix
by Felix 20 Jun '22

20 Jun '22

> We have released tor 0.4.7.8 earlier today, a new stable version for > the 0.4.7.x series containing an important High severity security > fix. The affected tor are only those of the 0.4.7.x series as in from > tor-0.4.7.1-alpha to tor-0.4.7.7. Jun 18 10:08:46.000 [notice] This version of Tor (0.4.7.8) is newer than any recommended version, according to the directory authorities. -- Cheers Felix

2 1