- tor-relays - lists.torproject.org

BSD tor ports/packages and impending 0.4.7.7 release
by George 03 May '22

03 May '22

BSD relay operators, like everyone else, should be aware that upgrading tor to 0.4.7.7 is critical for exit relays. The source is available now at: https://dist.torproject.org/tor-0.4.7.7.tar.gz Specifically for the BSD ports, here is the current status and workings. Any corrections appreciated. * DragonflyBSD https://github.com/DragonFlyBSD/DPorts/tree/master/security/tor Downstreams from FreeBSD quarterly updates, so may not have a 0.4.7.7 package or port for security/tor until July. * FreeBSD https://www.freshports.org/security/tor https://cgit.freebsd.org/ports/tree/security/tor https://svnweb.freebsd.org/ports/head/security/tor/ Updated to 0.4.7.7 already, and can be installed from security/tor now. Working fine at this point. For pkg(8) users, ensure that /etc/pkg/FreeBSD.conf line 11 is set to "latest", as opposed to "quarterly", which should be the case regardless of this security/tor release: url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", * NetBSD https://pkgsrc.se/net/tor pkgsrc's current port of net/tor was updated to 0.4.7.7. The stable port is still on 0.4.6.10 at https://cdn.netbsd.org/pub/pkgsrc/stable/pkgsrc/net/tor/Makefile * OpenBSD https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/tor/ The -current net/tor has been updated to 0.4.7.7 and the package is available. For users running 7.1-stable, net/tor 0.4.7.7 will hopefully be officially backported. Users can also update net/tor from ports on -stable themselves easily enough. If you're not on 7.1-stable, consider upgrading immediately. Thanks. g

1 0

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

Another error
by onionize＠riseup.net 20 Apr '22

20 Apr '22

Hello, we tried a solution proposed by admin(a)for-privacy.net (deleting /var/lib/tor folder) but now we get another error: │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 204.13.164.118:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 154.35.175.225:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 199.58.81.140:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 86.59.21.38:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 171.25.193.9:443. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 131.188.40.189:80. Please correct. Please help us if you know why it happens

2 1

Tor 0.4.5.8 died: Caught signal 7
by Gary C. New 19 Apr '22

19 Apr '22

All: I'm having an issue with a Tor Node catching signal 7 and exiting in high-load situations. ============================================================ T= 1650367869 Tor 0.4.5.8 died: Caught signal 7 /opt/sbin/tor(+0x1af500)[0x2a1af500] /opt/sbin/tor(hs_intro_received_introduce1+0x0)[0x2a09e6b8] /opt/sbin/tor(hs_intro_received_introduce1+0x0)[0x2a09e6b8] Anyone experience similar issues? Respectfully, Gary

1 0

Bridge Distribution Mechanism none
by Ross Camm 19 Apr '22

19 Apr '22

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

3 2

Instabilities in Hydra family expected
by abuse-node49＠posteo.de 19 Apr '22

19 Apr '22

Hello network! I would like to briefly inform that I have repeated problems with the hoster Yourserver.se, where I run some exit relays. Again a relay was deactivated with the message "Botnet". At that time I wrote a detailed explanation about the issue. I agreed to a temporary switch to a harmless relay, but as an exit operator I did not want to keep this state. So starting today the "Hydra family" will get some gaps which will take some time to replace. I know that there is an attempt to write a list of recommended providers somewhere. However, I have found that some of the information is not up to date. It is better to look into the Tor Metrics and find out the hoster for current exit relays that is mentioned there. Sometimes you are lucky. From my point of view, it should be possible to find out the age of exit relays from the Tor network database in relation to the hosters (ASxxxx) and thus find a ranking for reliability and suitability. Automatically, this would be a ranking for "privacy support". However, it would then be problematic that all newcomers would rely on these few hosters. Perhaps we will have to live with these problematic hosters and endure the dynamics. Here is a note about startup problems of the Tor service after a reboot: In my observation, this only happens with slow hardware and may also depend on the hypervisor. I use the same systems and configurations everywhere and see dead Tor services after startup only with the hoster Trabia.com and UDN (Ukrainian Data Network), with UDN working better now than a few years ago. It seems to be a timeout during start-up of the OS. With Debian "systemctl restart tor.service" solved the problem until the next reboot. With delayed start or a cron job this could be avoided, I assume. The fast hosters like * OVH.com, * Frantech.ca, * Flokinet.is, * Bahnhof.net * and Terrahost.com do not have the problem after reboot. First I will try to replace the failing VPS at Yourserver.se with reliable providers from my list, but I am checking other offers. I would also like to ask other participants in the network to name smaller, still unknown hosters. Kind regards Olaf

2 1

Tor Relay showing as down
by Alexandre Corradi Guerreiro 18 Apr '22

18 Apr '22

I have been running a ToR Relay for almost a year. https://metrics.torproject.org/rs.html#details/6C6C87A774A211F53DE5116A7A8A… and suddenly it stopped working. I don't see any errors on the logs but the relay is always showing in the relay search page as down. I even tried to upgrade the Tor client to a new version 0.4.6.10 to see if something changes, but no success. The process is running all the time, I see some circuit connections forming and after a while no more traffic going. Based on the syslog I see that everything looks fine, see next example. Apr 18 20:32:17 ubu01 Tor[1093]: Bootstrapped 10% (conn_done): Connected to a relay Apr 18 20:32:17 ubu01 Tor[1093]: Bootstrapped 14% (handshake): Handshaking with a relay Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 15% (handshake_done): Handshake with a relay done Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Apr 18 20:32:19 ubu01 Tor[1093]: Bootstrapped 100% (done): Done Apr 18 20:32:54 ubu01 Tor[1093]: New control connection opened. Apr 18 20:37:51 ubu01 Tor[1093]: External address seen and suggested by a directory authority: 187.74.71.95 Apr 18 20:38:17 ubu01 Tor[1093]: Now checking whether IPv4 ORPort 187.74.71.95:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Apr 18 20:39:20 ubu01 Tor[1093]: Self-testing indicates your ORPort 187.74.71.95:9001 is reachable from the outside. Excellent. Publishing server descriptor. Apr 18 20:40:27 ubu01 Tor[1093]: New control connection opened. Apr 18 20:42:20 ubu01 Tor[1093]: Performing bandwidth self-test...done. I tried to test my income connection from another computer to validate that there was no block on the ISP side, I could connect successfully to port 9001 as indicated on the logs. How can I troubleshoot this problem? -- Alexandre C Guerreiro

1 0