- tor-relays - lists.torproject.org

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

Article: The Growing Problem of Malicious Relays on the Tor Network
by Dirk 11 Dec '19

11 Dec '19

Dear all, I was made aware today of the article be nusenu [1]. Please read it. So even I theoretically new Sybil attack scenario against the tor network - I never was aware it could affect so much of the tor network infrastructure: "At their peak they reached >10% of the Tor network’s guard capacity". The article leaves me with some thoughts: + Due to the natrue of the tor network the problem can never be solved by 100% + How can the tor network be improved to be more resilient against this attach (Software & Operation) + Is there currently already activity ongoning by the tor project and how can we as organizations and operators support it best regards Dirk Tor support team digitale-gesellschaft.ch [1] https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-t…

3 2

Thinking of running bridge through Ubuntu Windows app and port question
by Keifer Bly 11 Dec '19

11 Dec '19

1 0

tor crashed: Could not apply consensus diff because an ed command was missing a line number.
by Winter Paulson 11 Dec '19

11 Dec '19

Hello, this morning the tor process crashed, couldn't find anything searching the internet. Any hints what this might have been: Tor[96521]: Could not apply consensus diff because an ed command was missing a line number. Tor[96521]: consdiff_gen_diff: Refusing to generate consensus diff because the generated ed diff could not be tested to successfully generate the target consensus. Tor[96521]: tor_assertion_failed_: Bug: src/lib/memarea/memarea.c:147: memarea_chunk_free_unchecked: Assertion sent_val == 0x90806622u failed; aborting. (on Tor 0.4.1.6 ) Tor[96521]: Bug: Assertion sent_val == 0x90806622u failed in memarea_chunk_free_unchecked at src/lib/memarea/memarea.c:147: . (Stack trace not available) (on Tor 0.4.1.6 ) server is running on openbsd. Thanks! w

2 1