tor-relays December 2019

tor-relays@lists.torproject.org

37 participants
28 discussions

tor 0.2.9.x reaches end of life on 2020-01-01
by nusenu 24 Dec '19

24 Dec '19

This is a reminder that tor version 0.2.9.x reaches its end of life date in a week (2020-01-01). Please upgrade your relays accordingly to avoid stability and security issues. https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… As of 2019-12-24 00:00 UTC there are still over 600 Tor relays making up >5% of the tor network's capacity running tor 0.2.9.x All affected relays: https://metrics.torproject.org/rs.html#search/version:0.2.9%20running:true Relay operators with a consensus weight > 9k and a usable contactinfo field got contacted directly. -- https://twitter.com/nusenu https://mastodon.social/@nusenu

1 0

Tor 0.4.2.5 - Unable to Run Tor Relay on Ubuntu 18.04 LTS VPS
by David Croft 23 Dec '19

23 Dec '19

Hi, I'm unable to start newly setup/configured guard/middle relay Tor version 0.4.2.5 after setup & configuration of Tor on an Ubuntu 18.04 VPS server. I'm already running a couple of Guard relays on Ubuntu 18.04 with the same VPS provider who allows for Tor Guard/Middle relays. I've followed a blueprint for setting up the Tor relay on Tor 0.4.2.5 which worked no problem on 6 other relays I've configured & operated without issue in the last month on Ubuntu 18.04 Tor version 0.4.1.6. I've carefully reviewed the steps I've taken to ensure I haven't made any errors during the setup/configuration process. The issue described here is accompanied by the arrival of 0.4.2.5 & this is, in fact, the first time I've tried to set up a Tor relay on 0.4.2.5. I've also included a screenshot that highlights the issues. I realize there might very well be other possible reasons for these errors, so I keep an open mind & will be grateful for any support or advice. Regards, Toni output from: systemctl status tor(a)default.service ● tor(a)default.service - Anonymizing overlay network for TCP Loaded: loaded (/lib/systemd/system/tor(a)default.service; enabled-runtime; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2019-12-22 16:33:12 CET; 40min ago Process: 3707 ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 (code=exited, status=0/SUCCESS) Process: 4643 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config (code=exited, status=1/FAILURE) Process: 4642 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /run/tor (code=exited, status=0/SUCCESS) Main PID: 3707 (code=exited, status=0/SUCCESS)

5 8

I am looking for a 36C3 ticket in Leipzig?
by Paul 21 Dec '19

21 Dec '19

Make my X-mass :-) Paul

1 0

Relay loosing FAST flag when upgrading from 0.4.1.5 to 0.4.2.5
by Ralph Wetzel 20 Dec '19

20 Dec '19

1 0

Announcing new tor fast exit
by Dennis Emory Hannon 20 Dec '19

20 Dec '19

Hello all, This is just a courtesy notification to let you know i have added an additional 100mbps unmetered (bare metal of course) exit within the last 48 hours. https://metrics.torproject.org/rs.html#details/29BBD80A1702C7FDEF6557C492F4… Thanks, -Dennis BackplaneDNS / Backplane LLC

1 0

Tor-bridge list
by lists＠for-privacy.net 19 Dec '19

19 Dec '19

Hello, I put a bridge on an unused server. Currently listed on Tor-metrics. https://metrics.torproject.org/rs.html#details/48022B9A9402CB6D9918C03B8AFD… But the IP per mail will soon have the "bad guy's". That would be too bad. With 2 Tor-instances, the server has reached 80-100 MiB/s Does the Tor-project have any other more secret bridge lists? Another question: Is it useful to offer other transport protocols than obfs4? -- ╰_╯ Ciao Marco!

2 2

Bridge Questions, Best Practices
by Eddie 19 Dec '19

19 Dec '19

Hi, Just setting up a new bridge, on a new VPS, to complement the relay I run at home and have a couple of questions regarding best practices. I set the bridge up from scratch, so it has no connections back to my relay fingerprint etc. as I understand that's "a bad thing". I've seen a few comments mentioning the lack of obfs4 bridges using port 443, so as I don't run any kind of webserver on the VPS I can do this. I also wanted to run an obfuscated bridge on port 80, but it seems that you can only run a single instance of obfs4. Searching around, the most common setup I found was this: ServerTransportListenAddr obfs3 [::]:80 ServerTransportListenAddr obfs4 [::]:443 Is this the best way to support both port 80 and 443, or is there a better way. Next, the ORPort. There seems to be confusing information about setting this up, in conjunction with obfs4proxy. Again, my setup: ORPort 9001 ORPort [--my public ipv6 address--]:9002 Again, is the the best way, as I've seen some information that says avoid 9001, but others say it's OK to use for a bridge, with obfs4proxy. Cheers.

2 2

Improving Relay IPv6 - RIPE Grant
by teor 18 Dec '19

18 Dec '19

Dear relay operators, I just wanted to let you know that RIPE has announced funding for The Tor Project to improve IPv6 support on relays. (RIPE is the European internet infrastructure organisation.) https://www.ripe.net/support/cpf/funding-recipients-2019 We'll have more details early in 2020, when we've worked out an implementation plan and a start time. Thanks for your patience with our current IPv6 support. And thanks to all those volunteer coders who have worked hard to get us this far. T -- teor ----------------------------------------------------------------------

7 13

unbound: error: recvfrom 123 failed: Host is down
by Winter Paulson 17 Dec '19

17 Dec '19

Hello, I'm running an exit relay > 200 Mbit/s with local unbound on openbsd. I receive a lot of the following syslog messages from unbound: unbound: [15040:1] error: recvfrom 226 failed: Host is down I already increased the UDP buffer sizes: net.inet.udp.sendspace: 262144 net.inet.udp.recvspace: 262144 (hopefully) relevant part from unbound.conf is: num-threads: 2 msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 rrset-cache-size: 100m msg-cache-size: 50m outgoing-range: 450 outgoing-port-avoid: "22,25,26,37,54,55,67,68,69,80,110,123,135,137,138,139,143,443,445,465,500,587,843,990,912,993,995,1025,1863,1935,2400,4242,4400,4421,4444,4445,4480,4500,4569,5038,5050,5060,5061,5062,5063,5064,5065,5198,5199,5200,5222,5555,5800,5801,5900,5901,6666,6667,6668,6669,7000,7001,7002,7003,7004,7005,7006,7658,7659,7660,7777,8050,8052,8054,8056,8058,8060,8080,8110,8118,8120,8123,8125,8143,8998,9001,9022,9030,9050,9051,9052,9053,9054,9055,9056,9057,9058,9059,9060,9080,10000,15000,15001,15002,15003,15004,16001,16999,20000,20001,25000,26999,29998,30600,31000,32000,36999,50300" outgoing-num-tcp: 25 incoming-num-tcp: 25 msg-buffer-size: 65552 I couldn't find any hints on the internet apart from increasing UDP buffers, any ideas what else to look for? Thank you! w.

2 3

Consensus Weight low when compared to Advertised Bandwidth
by Neel Chauhan 16 Dec '19

16 Dec '19

Hi, After having my Primcast.com dedicated server suspended, I signed up for a dedicated server from Psychz Networks in their Dallas location to run a FreeBSD-powered Tor exit relay. https://metrics.torproject.org/rs.html#details/9B6672E247BC4656915DF03A470D… While Psychz is a bit more expensive than Primcast/ServerRoom (and that is with an special offer), I get a slightly faster server and far better customer support. One problem is that the consensus weight value is rather low in proportion to the advertised bandwidth value, when they should be approximately similar. In fact, my server's CPU usage never goes beyond 1%. Is this normal now that sbws is being deployed? Or is it bad peering on my relay? -Neel === https://www.neelc.org/

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays December 2019