- tor-relays - lists.torproject.org

What is: Channel padding timeout scheduled
by Eddie 18 Oct '21

18 Oct '21

Noticed that one of my relays (OhNoAnotherRelay02) is showing as off-line. Looking at the logs, I see a bunch of these messages: Oct 18 08:39:16.000 [notice] Channel padding timeout scheduled 143041ms in the past. Oct 18 08:39:21.000 [notice] Channel padding timeout scheduled 156925ms in the past. Oct 18 08:39:24.000 [notice] Channel padding timeout scheduled 168712ms in the past. Oct 18 08:39:25.000 [notice] Channel padding timeout scheduled 166895ms in the past. . . . Oct 18 10:18:48.000 [notice] Channel padding timeout scheduled 194581ms in the past. Oct 18 10:35:22.000 [notice] Channel padding timeout scheduled 216311ms in the past. Oct 18 10:35:30.000 [notice] Channel padding timeout scheduled 224267ms in the past. What's the cause of this. I used this downtime as an excuse to do a bunch of upgrades and a re-boot. Cheers.

1 0

help with exit
by Bass Down Low 17 Oct '21

17 Oct '21

Hi all, I am somewhat new to the project and trying to run a couple exits to help out. I noticed my relay amazinglizard F80494CE5B2441B67431FFA9CCA571D26BC4F6D8 has bee up for 4 days and not turned into an exit yet. I noticed the overload flag is present, does this prefent my relay from becoming an exit? If not, I would appreciate any help you can give. thank you very much

2 1

Tor automatic restart
by Keifer Bly 11 Oct '21

11 Oct '21

7 8

Updating from Ubuntu 20.04 using apt-secure
by John Csuti 11 Oct '21

11 Oct '21

Hello all, I recently went to update and upgrade my system and found that the certificate for deb.torproject.org is expired and no longer trusted? Is anyone else having this issue and is there a way to fix this. I also added the repo to a fresh install of ubuntu 20.04 and got the same error. Error Err:5 https://deb.torproject.org/torproject.org focal Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 95.216.163.36 443] Thanks, John Csuti +1 (216) 633-1279

2 2

Restarting Tor
by sysmanager7 10 Oct '21

10 Oct '21

Greetings All, I have three relays that are in need of an upgrade and reboot. What is the best way to restart these relays without loosing flags or time? Secondly how long can a relay be down before flags are dropped? Thank you for any help! Sysop Sent with [ProtonMail](https://protonmail.com/) Secure Email.

4 3

relayor v21.1.0 is released
by nusenu 10 Oct '21

10 Oct '21

Hi, relayor v21.1.0 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 Changes since relayor v21.0.1 https://github.com/nusenu/ansible-relayor/releases/tag/v21.1.0 - generate ContactInfo v2 proof files for easy publishing (if enabled) - update apt cache if it is older than one day before installing dependencies (patch by @tsekityam) #219 #220 - increase min. ansible version 2.9.13 -> 2.9.23 - increase min. tor version 0.3.5 -> 0.4.5 - Debian 11, FreeBSD 13 and OpenBSD 6.9 are supported kind regards, nusenu -- https://nusenu.github.io

1 0

Connection Reset and IO Timeout errors on 0.4.6.7 with libnss
by theintern 09 Oct '21

09 Oct '21

Has anyone else on this list had issues with compiled versions of 0.4.6.7 in which the --enable-libnss is enabled?

1 0

Unreachable DirPorts
by Arlen Yaroslav 08 Oct '21

08 Oct '21

Hi to all relay operators! I run two Tor relays: 77D08850C1EE8587451F838D3F49874F75B0B1AC 09A70E396DE93F54D4541BBB0EC8E2B23761F34F They both have DirPorts configured on port 80. I can connect to this port on both hosts externally. However, Relay Search is showing the ports as either unreachable or unconfigured and is not showing the 'Latest server descriptor' and 'Latest extra-info descriptor' buttons at the bottom of the page. Would anyone be able help me troubleshoot this? Many thanks and regards, Arlen

2 1

Re: [tor-relays] Overloaded state indicator on relay-search
by Gary C. New 05 Oct '21

05 Oct '21

David Goulet: Will you confirm whether the Advertised Bandwidth metric is also client initiated (I'm assuming to the Directory Authority)? I have a 250Mb pipe and have seen a maximum Advertised Bandwidth rate of 4MB/s with my Tor relay. I know resource constraint must be factored in, but I would expect better than 4MB/s. I believe I remember reading it was based on an average 10 second burst rate, but in what direction is the connection initiated? Thanks, again. Gary

2 2

Re: [tor-relays] Overloaded state indicator on relay-search
by Bleedangel Tor Admin 29 Sep '21

29 Sep '21

1 0

New round of measuring the accuracy of Tor relays' advertised bandwidth
by Georg Koppen 23 Sep '21

23 Sep '21

Hello! You might recall we ran two "speed tests" so far for investigating the accuracy of a relay's advertised bandwidth, one in 2021[1] and another one earlier this year[2]. We gonna pick this test up again this week. However, this time it won't be just a single run but we are rather scheduling the experiment to be on for two weeks and then off for two weeks for the upcoming weeks/months (see: the third item in our network experiments strategy[3] for some rationale). More exactly: we'll run our measurement script for roughly one week, then wait about a week for flooded values leaving the relay descriptors, then 2 weeks off, then starting again... The experiment itself has not changed: we are planning to download several large data streams for a period of about 20 seconds with the goal to get a better estimation of the relay's true capacity. There are more details related to this experiment in particular in an older mailing list thread[1], in case anyone is interested and has not seen those yet. As in previous instances of this "speed test" there is the option for an opt-out. Let us know if any of you doesn't want to participate and we remove your relay(s) from the list to scan. Finally, an up-to-date status about the flooding being on/off (and other experiments scheduled) can be found on our status page[4]. Thanks, Georg [1] https://lists.torproject.org/pipermail/tor-relays/2019-July/017535.htmlff. [2] https://lists.torproject.org/pipermail/tor-relays/2021-May/019649.html [3] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Network-exper… [4] https://status.torproject.org/affected/network-experiments/

2 6

tor version question
by torix 22 Sep '21

22 Sep '21

Dear All, I can see in OrNetStats that I have several relays marked as having a vulnerable Tor version. But when I checked and tried to update them, I was told that everything was up to date. In 2 cases relays rented at the same time on the same host have different versions. AlexHost running FreeBSD release 12.1 and 12.2 respectively: 0.4.6.7 and 0.4.5.8 CoolComputers both running Centos8.4.2105: 0.4.6.6 and 0.4.5.10 I'm not sure why the same package repo would cough up different tor versions for different servers - is the answer to sit tight and wait for the older versions to catch up, or is there a way to force the older ones to update to a newer tor version? (My oldest version is 0.4.5.8). TIA, --Torix

2 2

Need help with Dir Address and Exit Address
by Bleedangel Tor Admin 21 Sep '21

21 Sep '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all I have an exit relay running, and all is working well. I am a stickler though, and i notice when i search my relay on the metrics page, the following two items are listed as 'none': Dir Address Exit Address Can anyone help me to get these reporting properly? I have a V2 Directory flag and my dir port is 9030. I am allowing ipv4 exits. Metric page for reference: https://metrics.torproject.org/rs.html#details/5161B1C501805A0D3E9F87AFCAC9… Thanks for any help you can give! -----BEGIN PGP SIGNATURE----- Version: ProtonMail wnUEARYKAAYFAmFJOgQAIQkQ07hp34FMyg4WIQSgEMifmnN5ohFWvfnTuGnf gUzKDs8DAP4hSvlEPrlDkIY5vlLULhJHuNVbq/UT3r5mfBg/cg+p0wEAltfV bPlU/3wfg7j0b31h6R4g+Ik+96fkoq9VTqiydQg= =6AAW -----END PGP SIGNATURE-----

2 1

Ripped off relay name
by xplato 20 Sep '21

20 Sep '21

Just curious a relay appeared with a nearly identical name to a relay I have run for a while. Is this just a lack of creativity or something that I should be concerned about? The name is fairly unique and the new relay is almost identical in name. Sent from ProtonMail for iOS

4 3

OrNetStats now parses all your ContactInfo v2 fields and warns you if your Tor version is vulnerable
by nusenu 15 Sep '21

15 Sep '21

today I pushed new features to OrNetStats: https://nusenu.github.io/OrNetStats/ - Relay Search replacement: relay level pages via a custom allium[1] version Thanks to Jordan for creating allium! - parse and display all ContactInfo v2 fields [2] example: https://nusenu.github.io/OrNetStats/w/relay/A14D96E6C4C3A5AF3D7E57AC0A85AE8… - proven operator domains are highlighted with an icon in all overview relay lists (family-, contact-, country-level pages) example: https://nusenu.github.io/OrNetStats/w/misc/families-by-bandwidth.html (we display the proven operator domain instead of the ContactInfo when available) - the icon links directly to the proof file from the operator (on the relay-level page) - we display a warning sign when a relay runs a vulnerable version of tor examples on relay and contact-level pages: https://nusenu.github.io/OrNetStats/w/relay/FB58E117D11F87F0A291475D603EC61… https://nusenu.github.io/OrNetStats/w/contact/17b90573a94e713bf1b3ad7988934… - we display bandwidth in G|Mbit/s not MByte/s - onionoo AS data replaced with ipfire's upstream version: we no longer use AS data from onionoo - which made the switch from previously used https://yui.cat links to a custom allium version necessary because yui.cat (allium) uses onionoo as data source. Previously over 2000 relays had no AS name data (which affected >25% of tor's exit capacity). Now we are down to bellow 0.1% affected exit capacity without AS name data (mainly in the LACNIC region). +------------+--------+-----------+ |date |affected| affected | | | relays | exit_prob | +------------+--------+-----------+ ... | 2021-09-06 | 2005 | 24.03 | | 2021-09-07 | 2025 | 27.33 | | 2021-09-09 | 2038 | 27.93 | | 2021-09-10 | 2045 | 28.45 | | 2021-09-11 | 2041 | 28.12 | | 2021-09-12 | 2045 | 28.70 | | 2021-09-13 | 2044 | 27.32 | | 2021-09-14 | 2029 | 26.44 | | 2021-09-15 | 108 | 0.05 | <<< todays switch from onionoo to ipfire +------------+--------+-----------+ kind regards, nusenu [1] https://github.com/tempname1024/allium [2] https://nusenu.github.io/ContactInfo-Information-Sharing-Specification -- https://nusenu.github.io

1 0

IPv6 reachability tests fail on CenturyLink IPv6 6rd - reachability broken?
by Neel Chauhan 13 Sep '21

13 Sep '21

Hi, I recently moved into a home with CenturyLink Fiber and moved my FreeBSD relays to the said home. Fingerprints: https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… In my relay logs, while IPv4 works fine, I get these IPv6 errors: Aug 26 18:47:01.000 [notice] Auto-discovered IPv6 address [REDACTED]:143 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. Aug 26 19:47:01.000 [notice] Auto-discovered IPv6 address [REDACTED]:143 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] CenturyLink does use 6rd for IPv6 in case that matters, however I can telnet the relay ORPort via IPv6 from a VPS. My firewall is an OPNsense box which terminates PPPoE/6rd. I am running tor-0.4.6.4-rc. Yes I know it's not the "latest", but I usually run the "beta" versions on my relays from FreeBSD pkg. Rebooting both my OPNsense box and my server doesn't work. The same relay fingerprints/torrcs/keys worked fine on Google Fiber/Webpass native IPv6 in another address. I'm guessing IPv6 reachability tests aren't working right now since it worked with CL 6rd earlier today, or maybe CL misconfigured their network. It's not a biggie for me, but while I could go Comcast with better IPv6, I'd rather have a high bandwidth relay than an IPv6 one with Comcast's slow uploads/caps. Other Seattle ISPs like Webpass, Wave, and Atlas aren't in my new home. -Neel Chauhan === https://www.neelc.org/

2 1

new tor network graphs on OrNetStats
by nusenu 10 Sep '21

10 Sep '21

Hi, up until now OrNetStats mainly consisted of tables with lots of numbers about tor network stats that can be interactively searched, but graphs are usually a lot easier to comprehend, that is why I'll be adding more graphs to OrNetStats. Today I've added the first new graph on the main page that shows the 10 largest proven exit operator domains and their exit fraction in a bar chart: https://nusenu.github.io/OrNetStats/index.html In the long run I plan to publish (and re-implement) all graphs that currently are nonpublic (and not on OrNetStats yet). This should give more people a better view / understanding about what is happening/changing on the tor network infrastructure. kind regards, nusenu -- https://nusenu.github.io

1 0

Relay Control Port
by sysmanager7 10 Sep '21

10 Sep '21

In torrc I have the control port commented out. I'm told the control port is not supposed to be listed on the relay itself. Below, is now what it says. How do I get rid of it? Control Socket: /run/tor/control GroupWritable RelaxDirModeCheck Thank you for your help :-) Sent with [ProtonMail](https://protonmail.com/) Secure Email.

3 2

Burning Bridges
by torix 10 Sep '21

10 Sep '21

I think I remember Roger Dingledine saying somewhere that bridges' ips gradually get learned and put on ban lists. I have some bridges bought for the year. When renewal time comes up, does it make sense to let them go and buy new vms for the next year rather than renew them? I don't know if it matters what pool a bridge is in. TIA, --Torix Sent with [ProtonMail](https://protonmail.com/) Secure Email.

2 1

router_do_orport_reachability_checks()
by Gary C. New 10 Sep '21

10 Sep '21

All: Does anyone here know the procedure of the router_do_orport_reachability_checks() function? I've increased logging of my Tor Relay to info and taken several packet-captures, but can't seem to identify connections initiated by my Tor Relay when verifying my ORPort reachability. I just see connections from other Tor Relays initiate connections with my Tor Relay. Any detail that can be provided regarding the procedure of the router_do_orport_reachability_checks() function is greatly appreciated. Respectfully, Gary

1 1

>50% tor exit capacity is now safer against ContactInfo impersonation attacks
by nusenu 09 Sep '21

09 Sep '21

Hi, when analyzing unusual activities on the tor network one of the problems always was the fact that tor relay ContactInfos are an unverifiable claim. This has been exploited by malicious entities multiple times to setup malicious relays using other people's contact details. Since the release of the ContactInfo Information Sharing Specification (version 2) in October 2021 there is an easy option to setup ContactInfo strings that contain a non-spoofable domain to address this issue. https://lists.torproject.org/pipermail/tor-relays/2020-October/019024.html By now over 900 tor relays have set a verifiable domain in their ContactInfo, and this week the landmark of 50% of the tor network's exit capacity has been reached. graph: https://nusenu.github.io/OrNetStats/exit-fractions (since so many operators implemented the spec the mouse-over on that graph is a bit overwhelmed - I'll fix that soon-ish :) It is important to note that a verifiable domain in a ContactInfo string does _not_ mean "this relay is certainly not malicious" after all malicious relay operators can setup verified domains as well with a domain under their control, but having non-spoofable operator identifiers are the foundation for operator trust based relay selection. It is easier to say "I trust www.quintex.com to operate relays without malicious intend" than to say "I trust CC14C97F1D23EE97766828FC8ED8582E21E11665,DE4F7A7B2DF8689B1F8D23ABA9E320D17638EAFD, ..." because relay fingerprints are not human readable and are more likely to change over time. In case you want to join the effort or simply would like to see your operator level graphs - a nice side effect (example: https://nusenu.github.io/OrNetStats/hydra-family.github.io.html) here is the short version on how to set a verifiable domain in your ContactInfo: https://mastodon.social/@nusenu/106094297537909911 Thanks to everyone who joined so far and indirectly helps with malicious relay analysis! kind regards, nusenu -- https://nusenu.github.io

1 0

Old version in Debian/Ubuntu repo?
by Eric Jacksch 05 Sep '21

05 Sep '21

Greetings, Just a heads-up that a fresh install on Ubuntu 20.04 as per https://community.torproject.org/relay/setup/guard/debianubuntu/ Results in a version warning in the log file: "Please upgrade! This version of Tor (0.4.2.7) is not recommended, according to the directory authorities. Recommended versions are: ...." Cheers, Eric

2 2

Did obfs4proxy stopped working for you on Debian Buster or Bullseye?
by s7r 03 Sep '21

03 Sep '21

Hello, Did you try running obfs4proxy on Debian Buster or Bullseye and it worked? For me it stopped working entirely. All it says is: [warn] Pluggable Transport process terminated with status code 256 Here is what I checked so far: - I am on Debian Bullseye with all packages up to date - go lang version is go1.15.9 linux/amd64 - obfs4proxy version is obfs4proxy-0.0.12-dev (compiled from git) - Tor version is 0.4.7.0-alpha-dev I have edited /lib/systemd/system/tor(a)default.service & tor@.service to NoNewPrivileges=no and also installed libcap2-bin and setcap +ep to obfs4proxy executable. The libcap2-bin step is because I want to bind to a lower port, but even if I try to bind to a higher port like 50001 it will still not work and report the same: Pluggable Transport process terminated with status code 256. On another server I did a software upgrade from stretch to buster by apt dist upgrade and obfs4proxy stopped working as well. I am still digging here cause there are chances I did some mistakes while upgrading, so I am just mentioning the Bullseye problem because there are no excuses there, it should work, it's a clean fresh new install from scratch. Can someone please have another look to see if the problem is just on my side or if it's persistent among Bullseye installs, we should update the wiki bridge howto. Thanks.

1 2

Inflated throughput measures from torproject metrics?
by torix 02 Sep '21

02 Sep '21

The advertized bandwidth of my aramis family of relays has gone up from around 45 to 67 total since last week. ZimmerLinux (quetzalcoatl) sees inflation as well. I found a graph here of quetzalcoatl: https://nusenu.github.io/OrNetStats/quetzalcoatl-relays.org.html which whose weekly graph currently shows everything staying the same until about Wed. 25 Aug., then creeping up. He hasn't added any relays, so it looks as though the bwauths have changed something. I'm bringing this up because something seems a little out of control here. TIA, --Torix

2 6

Expected relay performance
by fugel1 31 Aug '21

31 Aug '21

Hi all! I've been running two tor relays [1] on the same machine for the past three weeks or so on my home connection (1 gigabit fibre). When I was looking for appropriate hardware (I needed something fanless) I was surprised at the almost complete absense of information online about what kind of relay performance one can expect from different cpus. Until the current relays speedtest that started on August 25 [2], my relays were slowly ramping up to about 4 MB/s up and down with a consensus weight of 15-19000. Hence, I was expecting to have to wait a few months to find out what the hardware was capable of, BUT then the mentioned test started! Both my relays instantly got an advertised bandwidth over 70 MB/s, and soon after consensus weights of 85000 and 105000 respectively (maatuska even hade the latter at 190000 for a while). The relays are now pushing over 20 MB/s each which enables me to start filling the current performance information void with the following: A fanless Core i5-8250 with HT disabled, running OPNSense 21.7.1, can push 22 MB/s of tor traffic up and down on each of two tor instances, with each main tor process consuming no more than 50 percent of one core and an average across all cores of 35-38 percent. Sorry about the lengthy post! :) [1] https://metrics.torproject.org/rs.html#details/F387C5F92B784137933202BB5E4F… [2] https://status.torproject.org/experiments/2021-08-26-relay-speed-test/

1 0