- tor-relays - lists.torproject.org

Exit Relay throughput
by torix＠protonmail.com 20 Jun '20

20 Jun '20

Dear List, How important is the throughput on an exit relay? I realize that more is always better, making it harder to associate exit packets with input ones at the other end. My numbers: For the same price I can buy 2 exit relays that run about 3500 to 4000 connections or one that runs about 4300 to 4700 connections. The actual daily throughput varies a good deal, but the cheaper ones show about 15-20% less throughput, at around 330 GiB/day when I look at vnstat. Can I assume 2 is almost always better than one? Or is there a threshold below which packets are too easily tracked? I have no common sense about this. TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

"/var/tor/diff-cache" full!
by Salvatore Cuzzilla 18 Jun '20

18 Jun '20

Hi Folks, I'm running a non-exit relay (v0.4.2.7) on OpenBSD 6.7. The amount of files within "/var/tor/diff-cache" is steadily increasing. Up to almost 6G fulfilling the /var partition to the max. Is this an expected behavior? I there any solution to overcome it? ------- :wq, Salvatore.

5 5

directory servers working on updates?
by Paul Geurts 16 Jun '20

16 Jun '20

hi, anything up this weekend? [image: image.png] gr. Paul

2 2

ymkeo changing ISP coming Thursday
by René Ladan 14 Jun '20

14 Jun '20

Hi, I'm in the process of switching ISPs and if all goes well this should be complete by coming Thursday. So my relay (ymkeo, 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D) will change its external IPv4 and IPv6 addresses. It is listed as a fallback directory mirror but currently not acting as one, so someone will have to update that list :) New IPv4: 185.238.129.9 /32 New IPv6: 2a10:3781:116:: /48 Regards, René

1 0

Consensus weight/Advertised bandwidth low on "Gigabit" ISP, despite ISP equipment upgrades
by Neel Chauhan 14 Jun '20

14 Jun '20

Hi tor-relays@, I run a FreeBSD-based Tor relay across two instances on "Wave G", a Gigabit ISP in the Seattle metro. You may also know them as CondoInternet or CascadeLink, but I joined only this year on a Wave-branded service. These relays have had low consensus weights since I got the service in January. The instances are below: * https://metrics.torproject.org/rs.html#details/8FABF4D266DF95216F6C646C6D6D… * https://metrics.torproject.org/rs.html#details/CE06BA1EA45FD32A79EAF7FE6A3B… My server and router are fine, I am in the single digits in terms of CPU use on both. The same exact server and router on Verizon FiOS in New York never gave me this issue. There was an underlying ISP performance issue impacting me which led consensus weight values to be low, but my ISP has since upgraded their equipment in my building. In general, my Internet performance has improved by magnitudes. However, my consensus weight has stayed more or less flat since the equipment upgrade, instead of jumping higher. What gives? How long would it usually take for the bandwidth scanners to measure the higher bandwidths? Should I re-key my relays and start from scratch? About switching ISPs, I'm not switching to Comcast for obvious well-documented reasons, and neither CenturyLink nor Frontier/Ziply Fiber serve me, not even copper. Best, Neel Chauhan === https://www.neelc.org/

2 1

IPv6 Port
by Josh Lawson 11 Jun '20

11 Jun '20

I currently have my IPv6 connection running on port 9001. From an anti-surveillance perspective, would I be better changing the port to 80? I have IPv4 running on 443. I appreciate it!

2 3

[NYX_NOTICE] Relay unresponsive -- how to troubleshoot?
by Davin Mertens 11 Jun '20

11 Jun '20

I keep getting NYX_NOTICEs about "Relay unresponsive". They happen every few hours, and last for minutes or sometimes a couple of hours before I get a "relay resumed" message. But, I don't see anything in the actual Tor logs to indicate that anything is wrong. Does anyone know how best to troubleshoot this? I *think* it's impacting my consensus weight and making it drop, and is keeping me from getting the Guard flag. This is the relay: https://metrics.torproject.org/rs.html#details/94626BD21119568EB301D1E7677B… Thanks for any tips!

3 3

Q: Is my bridge up?
by torix＠protonmail.com 10 Jun '20

10 Jun '20

I put up a new bridge and thought things were okay; I could see outbound, sometimes inbound connections in nyx, and seemed to have some throughput in the first nyx screen. The start up log lines seem okay: "Jun 10 11:05:07.000 [notice] Bootstrapped 100% (done): Done Jun 10 11:05:07.000 [notice] Now checking whether ORPort 108.52.155.127:11340 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Jun 10 11:05:09.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 10 11:06:09.000 [notice] Performing bandwidth self-test...done. Jun 10 14:13:20.000 [notice] New control connection opened. Jun 10 15:33:16.000 [notice] No circuits are opened. Relaxed timeout for circuit 133 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. Jun 10 16:25:18.000 [notice] New control connection opened." And the 6hr heartbeat seems to show stuff is happening" "Jun 10 17:05:06.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 1.91 MB and received 5.84 MB." But when I use the bridge reach-ability test at https://bridges.torproject.org/scan/ It fails to find my obfs4 port. I have the two ports port-forwarded in my local router, but when I turn on ping to the router, nmap from outside sees them as filtered. Am I sending people down a black hole? Because tor does seem to be making tor connections. TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 3

Anyone getting Failed to find node for hop #2 of our path. Discarding this circuit. on relays after update?
by s7r 10 Jun '20

10 Jun '20

Hello, I have upgraded Tor to 0.4.5.0-alpha-dev-20200609T194914Z-1~d9.stretch+1 yesterday and got this message on all relays and bridges after upgrade: [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [notice] Our circuit 0 (id: 4) died due to an invalid selected path, purpose Testing circuit. This may be a torrc configuration issue, or a bug. [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. ... like 10-14 more times same message ... It eventually healed by itself on some relays, and on some only after another restart of the Tor process. I am only wondering if anyone else got this. What made me want to ask this is what I somehow got it on each and every relay and bridge I did the update on. Could this be triggered by a skewed clock? The virtual machines usually start with hwclock which is usually behind (virtualbox bug) and few seconds after boot ntp takes over and corrects the time. Will keep an eye on this. Things appear to run fine after it starts. Thanks.

1 0

Help via Skype teamviewer
by Pac-Man 10 Jun '20

10 Jun '20

I have everything ready to roll with a fresh Ubuntu install all updated could I get configuration help via Skype and teamviewer? Rgds, Pac-Man Sent from ProtonMail Mobile

3 2