- tor-relays - lists.torproject.org

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

Obfs4 Bridge/Relay Issue
by texasbuckeye＠riseup.net 10 Dec '19

10 Dec '19

I have been trying to run a relay/obfs4 bridge from my Macbook (macOS Catalina 10.15.1) for some time now. I want to do it to help out the Tor network - getting a Tor t-shirt would be a nice bonus. I've already donated to help out until I can get my bridge/relay up & running. I've been starting out with trying to run an obfs4 bridge with the intent to move to a full relay (non-exit) at a later date. I've tried setting up my ORPorts to 80, 443, 9050, auto, and many others. I use Bitdefender as my antivirus software (which doesn't really show open/closed/used ports; nor does the built-in firewall in System Preferences in macOS. Below is my torrc file and log files (from Console). If you see any mistakes or any reasons why I cannot get the obsf4 bridge or relay to run please let me know. I have been trying to get this to work for a few months now. I upgraded to Tor 0.4.1.6 to see if that makes a difference and so far nothing has changed. Any assistance that you could give would be greatly appreciated. Thank you in advance for your assistance. ** *_Torrc_:* #Bridge config RunAsDaemon 1 ORPort 80 ORPort 443 ORPort 9050 ORPort auto BridgeRelay 1 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy # For a fixed obfs4 port (i.e. 9002), uncomment the following line. #ServerTransportListenAddr obfs4 0.0.0.0:9002 # Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means # "extended", not "external". Don't try to set a specific port number, nor listen on 127.0.0.1 ExtORPort auto ExitRelay 0 ExitPolicy reject *:* # no exits allowed ## Send all messages of level 'notice' or higher to /opt/local/var/log/tor/notices.log Log notice file /usr/local/var/log/tor/notices.log # Contact information that allows us to get in touch with you in case of # critical updates or problems with your bridge. This is optional, so you # don't have to provide an email address if you don't want to. ContactInfo 0x4DD6289CAD37F299 <texasbuckeye AT riseup DOT net> # Pick a nickname that you like for your bridge. Nickname texasbuckeye ## Define these to limit how much relayed traffic you will allow. Your ## own traffic is still unthrottled. Note that RelayBandwidthRate must ## be at least 75 kilobytes per second. ## Note that units for these config options are bytes (per second), not ## bits (per second), and that prefixes are binary prefixes, i.e. 2^10, ## 2^20, etc. RelayBandwidthRate 1000 KBytes # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 2000 KBytes # But allow bursts up to 200KB (1600Kb) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *_Console_:* Nov 23 17:34:12.000 [notice] Tor 0.4.1.6 opening log file. Nov 23 17:34:12.475 [notice] Tor 0.4.1.6 running on Darwin with Libevent 2.1.11-stable, OpenSSL 1.0.2s, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A. Nov 23 17:34:12.476 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Nov 23 17:34:12.477 [notice] Read configuration file "/usr/local/etc/tor/torrc". Nov 23 17:34:12.481 [notice] Based on detected system memory, MaxMemInQueues is set to 6553 MB. You can override this by setting MaxMemInQueues by hand. Nov 23 17:34:12.483 [notice] Opening Socks listener on 127.0.0.1:9050 Nov 23 17:34:12.484 [notice] Opened Socks listener on 127.0.0.1:9050 Nov 23 17:34:12.484 [notice] Opening OR listener on 0.0.0.0:0 Nov 23 17:34:12.484 [notice] OR listener listening on port 57054. Nov 23 17:34:12.484 [notice] Opened OR listener on 0.0.0.0:57054 Nov 23 17:34:12.485 [notice] Opening OR listener on 0.0.0.0:9050 Nov 23 17:34:12.485 [notice] Opened OR listener on 0.0.0.0:9050 Nov 23 17:34:12.485 [notice] Opening OR listener on 0.0.0.0:443 Nov 23 17:34:12.485 [notice] Opened OR listener on 0.0.0.0:443 Nov 23 17:34:12.485 [notice] Opening Extended OR listener on 127.0.0.1:0 Nov 23 17:34:12.486 [notice] Extended OR listener listening on port 57055. Nov 23 17:34:12.486 [notice] Opened Extended OR listener on 127.0.0.1:57055 Nov 23 17:34:14.000 [notice] Parsing GEOIP IPv4 file /usr/local/Cellar/tor/0.4.0.5_1/share/tor/geoip. Nov 23 17:34:14.000 [notice] Parsing GEOIP IPv6 file /usr/local/Cellar/tor/0.4.0.5_1/share/tor/geoip6. Nov 23 17:34:14.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Nov 23 17:34:14.000 [notice] Your Tor server's identity key fingerprint is /<REDACTED>/ Nov 23 17:34:14.000 [notice] Your Tor bridge's hashed identity key fingerprint is /<REDACTED>/ Nov 23 17:34:14.000 [notice] Bootstrapped 0% (starting): Starting Nov 23 17:34:20.000 [notice] Starting with guard context "default" Nov 23 17:34:20.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Nov 23 17:34:21.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Nov 23 17:34:21.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay Nov 23 17:34:21.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done Nov 23 17:34:21.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Nov 23 17:34:21.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Nov 23 17:34:21.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit Nov 23 17:34:22.000 [notice] Guessed our IP address as xx.xxx.x.xxx (source: 51.77.251.192). Nov 23 17:34:22.000 [notice] Bootstrapped 100% (done): Done Nov 23 17:34:22.000 [notice] Now checking whether ORPort xx.xxx.x.xxx:57054 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Nov 23 17:35:31.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 192 buildtimes. Nov 23 17:36:23.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for socks info) Nov 23 17:36:23.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for socks info) Nov 23 17:36:23.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for socks info) Nov 23 17:36:23.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for socks info) Nov 23 17:36:23.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for socks info) Nov 23 17:54:22.000 [warn] Your server (xx.xxx.x.xxx:57054) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Nov 23 18:14:22.000 [warn] Your server (xx.xxx.x.xxx:57054) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc **** Note: all of the xxx.xxx.x.xx are from me blanking out my IP address. It shows up correctly in the torrc file.**** -----BEGIN PGP PUBLIC KEY BLOCK----- mDMEXIAIQxYJKwYBBAHaRw8BAQdAi+6O3V0xtSKmzucYuorDwp28gTRYAfcwU4sB lssAAZe0JlRleGFzQnVja2V5ZSA8dGV4YXNidWNrZXllQHJpc2V1cC5uZXQ+iJkE ExYIAEECGyMFCRLP+d0FCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQS0RSz6yB/a nBSqFTlN1iicrTfymQUCXNvNewIZAQAKCRBN1iicrTfymV13AP9JbmdW96JV5l6o 0JYIKBf4nDO9mPmgUPcjNOmJFeBL4AEAhzt42B5+8EwBcA3vunO3jCSjuRGP/6rZ FpHQZuxm4AOIlgQTFggAPhYhBLRFLPrIH9qcFKoVOU3WKJytN/KZBQJc27BFAhsj BQkSz/ndBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEE3WKJytN/KZkPwA/i4E vtUmW86CFWZKsLRbRdYEHnJ5Oi5WgFTo+6X4Zq/9AQDBHA5TrC3C2uUIVj+O+SaO +rulUWIRQJoehkLQu9D7BYh4BDAWCAAgFiEE3IsxO+F1w2ZOL0j2hRvwao1NOh8F Al0ukMMCHQAACgkQhRvwao1NOh8m1gD9EPykgY/o5AyFWzLGCbiy0JeKhCdVCKRP nvAPDfuJpfgBAOBLFGeXlmwVAKByV24ZIPkS6m1cIJXty+5ICaYzMXAJiHUEEhYI AB0WIQTcizE74XXDZk4vSPaFG/BqjU06HwUCXNw+ygAKCRCFG/BqjU06HxJ9AP0U bSEsin9oR2tHJCbSFgMR4UoAVYlEF/ZBrbXxmoeqTAEAiu5cBOnP8IKE4DUvo/sL +tlfoLYFfcO7OLktLgptzAa0KFRleGFzQnVja2V5ZSA8VGV4YXNCdWNrZXllQHR1 dGFub3RhLmNvbT6IlgQTFggAPgIbIwUJEs/53QULCQgHAgYVCgkICwIEFgIDAQIe AQIXgBYhBLRFLPrIH9qcFKoVOU3WKJytN/KZBQJc2817AAoJEE3WKJytN/KZAswA /iD1qlN9hz+wsJTLJ1LhGmnpC/s/ENrxqRYrHOh/jo6DAP9GjIIcy+dHXR4dHjHz xCdkcixT2uQlY/ohUMub5oI1DYiZBBMWCABBAhsjBQkSz/ndBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAFiEEtEUs+sgf2pwUqhU5TdYonK038pkFAlywpgMCGQEACgkQ TdYonK038pmyiQEAqqjXz6k5PC1zTfoJz3n3teNNDpW5v9K/GqN1a2yLC3UBAMVi d8QzRGdDPS3b7v2S9rJyzmVG4ZkB1Hq+plzbYR4IiHUEEhYIAB0WIQTcizE74XXD Zk4vSPaFG/BqjU06HwUCXNw+ygAKCRCFG/BqjU06H44HAP403wGCcNDxv/0uFq2x tfrWL5JHohrbMjpAzwNzL2LdMwEAg/csDos6TdkIeLnWFc4LtB/LgHHKiOd+2zIm WmN7xg6IeAQwFggAIBYhBNyLMTvhdcNmTi9I9oUb8GqNTTofBQJdLpDpAh0AAAoJ EIUb8GqNTTof6EsBAOyLDzGmdWayt4rGZ+Uwf5Lge3MCmOcqMb1AbxyWK2JDAP9T +iIBTkoRYAaxh0h2W4zhumjaP5ZA+Fb1KYKBnr9mAIh4BDAWCAAgFiEE3IsxO+F1 w2ZOL0j2hRvwao1NOh8FAl0ukMMCHQAACgkQhRvwao1NOh8m1gD9EPykgY/o5AyF WzLGCbiy0JeKhCdVCKRPnvAPDfuJpfgBAOBLFGeXlmwVAKByV24ZIPkS6m1cIJXt y+5ICaYzMXAJtA5BZGFtIE1hc3RlcnNvbohzBBAWCAAdFiEELwyJjjmCTGqwXHP3 9rXSUZStES8FAlyACL8ACgkQ9rXSUZStES8pxAEArMwqHp9C/mEr3h/sCM15MHv8 jT4bAhwr0ZFBQ+RORr0A7iiDgKHnJgf2ECyR1xlDldq56Rklswk84LTkMM3ECYh4 BDAWCAAgFiEEtEUs+sgf2pwUqhU5TdYonK038pkFAl1An54CHQAACgkQTdYonK03 8plHVgD+J1n6Sn6VgjFeWS4Ly3/7oXvy+WrpQyp/FT2vunqPfZsA/jEKXB3jbnms Ewa0hFwYCbu54l04N1xwyT4g6Hiqr98CiJYEExYIAD4WIQS0RSz6yB/anBSqFTlN 1iicrTfymQUCXIAIQwIbIwUJEs/53QULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAK CRBN1iicrTfymVySAQCjXY0u4JbOkKg7gesuGv4+f0Qcj1kpmIRl07bjoRGFMQD9 ERq9Y2QGrh8J6WvpYJiezmKWpAb2gUJU2FR0pxdSJQ+4OARcgAhDEgorBgEEAZdV AQUBAQdAtphO/5HvjrYwz/niPQuh86fAHLmv6DnGqunYP6dbjxUDAQgHiH4EGBYI ACYWIQS0RSz6yB/anBSqFTlN1iicrTfymQUCXIAIQwIbDAUJEs/53QAKCRBN1iic rTfymfheAPwMNkHpw+TSS1Lo4yZVUAsBXjlB9hhQK4y9hfLCTkR0QwD/eE0VFOve smbXgFikwfPmCrja9+uuHCfTtzDaF9pojAOIeAQwFggAIBYhBNyLMTvhdcNmTi9I 9oUb8GqNTTofBQJdLpDDAh0AAAoJEIUb8GqNTTofJtYA/RD8pIGP6OQMhVsyxgm4 stCXioQnVQikT57wDw37iaX4AQDgSxRnl5ZsFQCgclduGSD5EuptXCCV7cvuSAmm MzFwCYh4BDAWCAAgFiEE3IsxO+F1w2ZOL0j2hRvwao1NOh8FAl0ukOkCHQAACgkQ hRvwao1NOh/oSwEA7IsPMaZ1ZrK3isZn5TB/kuB7cwKY5yoxvUBvHJYrYkMA/1P6 IgFOShFgBrGHSHZbjOG6aNo/lkD4VvUpgoGev2YA =pP1Y -----END PGP PUBLIC KEY BLOCK----- -- texasbuckeye(a)riseup.net OpenPGP Fingerprint: 0xB4452CFAC81FDA9C14AA15394DD6289CAD37F299

2 1

Stable and fast flags
by David Strappazon 04 Dec '19

04 Dec '19

Hi, How long is it supposed to take to get the stable and fast flags? My bridge is up since 13 days. At the beginning I had both flags then I lost them because of a reboot I think. Since, they never came back. Envoyé depuis ProtonMail mobile

2 2

Re: [tor-relays] New operator
by entensaison＠use.startmail.com 04 Dec '19

04 Dec '19

On Thursday, November 21, 2019 at 7:29 PM, Mario Costa <mario.costa(a)icloud.com> wrote: > >> Il giorno 21 nov 2019, alle ore 15:49, Matt Traudt >> <pastly(a)torproject.org> ha scritto: >> >> Thanks for running a bridge. >> >> Check Tor's logs to make sure it is actually running and doesn't >> report >> issues. Search its hashed fingerprint on >> https://metrics.torproject.org/rs.html and make sure it is listed as >> up. >> Verify you did *not* set 'PublishServerDescriptor 0'. Verify you can >> use >> your bridge from outside your home. I once had a residential ISP >> that >> blocked inbound port 80 but not 443. > This actually made me realize that my home router would not properly > forward ports 80 and 443 from outside. I could connect to my bridge > from the LAN (even using my external IP) but not from outside. I had > to change to a non-standard port, unfortunately, because apparently > 80 and 443 are used by the router’s web GUI even if I disabled > external access to it. That’s a shame because I understand that ports > 80 and 443 are less likely to be blocked by censors. > > However, it’s still not clear to me how I can confirm anyone is using > the bridge. In the nyx log you see messages like 'In the last X hours we have seen X unique clients' (I don't remember the exact wording) Those are the clients that did use your bridge. > When I connect to it, all I see in nyx are OUTBOUND connections and > not even one inbound connection (maybe that’s by design in order to > protect connecting users' privacy, I don’t know). You are probably right. In the past you could see connecting users in nyx as inbound connections without visible IP-address. Now they are not displayed as inbound connections any more. The outbound connections that are needed for these users are still displayed.

3 2