- tor-relays - lists.torproject.org

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