- tor-relays - lists.torproject.org

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

22 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 20 Dec '19

20 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 17 Dec '19

17 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 11 Dec '19

11 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

Probabilities
by Vitor Milagres 04 Dec '19

04 Dec '19

What do guard, middle and exit probabilities mean? Say, for example, that the middle probability for a certain relay is 0.15% and the guard probability for the same relay is 0.20%. What does that mean? Thanks

2 1

Accounting limits seem to cause permanent hibernation
by Manuel Wiesinger 03 Dec '19

03 Dec '19

Hello everyone, I configured an accounting limit on my tor relay. 1-2 days after restarting the tor service the relay seems to go into permanent hibernation. Once I restart the service traffic is sent and received as expected, however after 1-2 days it seems to go into permanent hibernation again until I restart the service. The longest hibernation period was for about three month(!). My configuration: Tor 0.4.1.6, on FreeBSD 12.1. (nothing else running on the machine) My relevant settings: AccountingMax 128 GBytes AccountingStart day 00:00 RelayBandwidthRate 2560 KBytes RelayBandwidthBurst 5120 KBytes Logs since the last restart: https://pastebin.com/wk04zDC8 Metrics: https://metrics.torproject.org/rs.html#details/A3BB86337E003A2668E016466EA3… (The peeks in the graphs match the times when I manually restarted the service) Since I experience this 'permanent hibernation' since at least last August, I wonder if it's expected behavior, e.g., caused by the small limit of 128 GB per day, or if it's a bug (possibly related to this one: https://lists.torproject.org/pipermail/tor-relays/2019-October/017862.html ?). Best, Manuel

3 3

Version 0.3 of obfs4 bridge docker image released
by Philipp Winter 28 Nov '19

28 Nov '19

We recently released version 0.3 of our obfs4 bridge docker image. To upgrade to the new image or deploy a new container from scratch, please take a look at our instructions: <https://community.torproject.org/relay/setup/bridge/docker/> Here's what changed in our new version: * We added a new script, 'get-bridge-line', which prints your bridge line. Run it as follows: docker exec CONTAINER_ID get-bridge-line * We improved our setup instructions. As part of this, we added a Makefile that facilitates the process of deploying a container. Here are the new instructions: <https://community.torproject.org/relay/setup/bridge/docker/> * Our new Makefile uses docker volumes to persistently store tor's data directory. This means that you can now upgrade to future docker images (which involves deleting your existing container) while keeping your bridge's identity. * We made tor log to stdout in addition to its log file, so the following command now shows tor's entire log output, and not just the first few lines. docker logs $CONTAINER_ID * The bridge can now bind to obfs4 ports < 1024. * One can now run multiple bridge containers on a single machine. Thanks to thymbahutymba for providing a great template for our Makefile and for suggesting docker volumes. Cheers, Philipp

1 0

MyFamily line commented out but stays valid?
by [REDACTED] 26 Nov '19

26 Nov '19

Hi, when i comment out the MyFamily line with an # in the torrc on one relay it seems to be still handled like before. Hitting x in nyx or waiting a few days or rebooting does not make any change. Is this expected? I expected that relay to show as part of no family now and listed as "Alleged Family Member" on all other relays which still list that fingerprint in their torrc.

5 7

switching ISP and Fallback listing
by René Ladan 25 Nov '19

25 Nov '19

Hi, I might switch my ISP soon-ish from XS4ALL to Freedom Internet so my relay [1] will get a new AS number and IPv4/IPv6 address, how does this impact being listed as a fallback candidate? I'm currently not selected as a fallback. (And yes, I know about fallback needing to be long-term reliable, but this event was caused by the big corporate powers :( ) Thanks, René [1] https://metrics.torproject.org/rs.html#details/4E8CE6F5651E7342C1E7E5ED031E…

2 1

bridge relay search is "wrong"
by David Strappazon 24 Nov '19

24 Nov '19

Hi, My bridge appears down when checking "tor relay search" on smartphone and up when checking the site from a laptop. Is there a reason? does someone already had the same issue? Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 4

Newbie question about bridge
by David Strappazon 22 Nov '19

22 Nov '19

Hi, all I configure a bridge on October the 31th. On the first days I had to reboot it multiple times but few days later I had all the necessary flags, fast and stable include. Now I'm at 9+ days of uptime, I lost the fast and stable flags and the advertised bandwidth is at 792 KiB/s when my bandwidth is configured at 3 MB/s with burst at 6 MB. Of course I haven't seen a single client. My question is: is it normal and part of a relay/bridge lifecycle or is there something wrong? Ps: on metrics.torproject.org, everything is fine. Nothing wrong in my logs either and I can use it when configuring my it in a tor browser. Any opinions or advices would be welcome. David. Envoyé depuis ProtonMail mobile

1 0

New operator
by Mario Costa 22 Nov '19

22 Nov '19

Hello everyone, I have some newbie questions and I hope this is the right place to ask them. I started operating a relay on my VPS for a bit more than a month and everything seems to be going well. I constantly have about 200 outbound and 2000 inbound connections, but in nyx I almost never see any circuits. What does it mean? Do I see circuits only when someone is actually using my relay, i.e. in Tor Browser? To further support the project I decided to run a bridge at home using a Raspberry Pi. How do I know when it is being used? I rarely see any traffic. Sometimes I see one outbound connection in nyx and some circuits open, but I never see an inbound connection to port 80 (the obfs4 port I chose). Why does the bridge have open circuits more often than the relay? I couldn’t find any answers online, so I hope to clear things out here. Regards, m. _____________________________________________________________ GPG fingerprint: 6C3B 0069 30C4 0F16 E5F6 690E 7D2E 100E C3C4 7105 <https://keys.openpgp.org/vks/v1/by-fingerprint/6C3B006930C40F16E5F6690E7D2E…>

2 2

Assertion pol->magic failed
by Logforme 22 Nov '19

22 Nov '19

Tonight my relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 restarted with the following in the log file: Nov 20 19:08:07.000 [notice] Heartbeat: Tor's uptime is 20 days 12:00 hours, with 29939 circuits open. I've sent 46193.23 GB and received 45940.92 GB. Nov 20 19:08:07.000 [notice] Circuit handshake stats since last time: 36379/36379 TAP, 591207/591207 NTor. Nov 20 19:08:07.000 [notice] Since startup we initiated 0 and received 655 v1 connections; initiated 0 and received 191219 v2 connections; initiated 1 and received 191367 v3 connections; initiated 75189 and received 1351289 v4 connections; initiated 147903 and received 1783201 v5 connections. Nov 20 19:08:07.000 [notice] DoS mitigation since startup: 11 circuits killed with too many cells. 3810290 circuits rejected, 67 marked addresses. 349630 connections closed. 7988 single hop clients refused. Nov 21 00:18:01.000 [err] tor_assertion_failed_(): Bug: ../src/core/or/circuitmux_ewma.c:165: TO_EWMA_POL_CIRC_DATA: Assertion pol->magic == 0x761e7747U failed; aborting. (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: Assertion pol->magic == 0x761e7747U failed in TO_EWMA_POL_CIRC_DATA at ../src/core/or/circuitmux_ewma.c:165: . Stack trace: (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x47) [0x55d5e9f968e7] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x147) [0x55d5e9f919c7] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0x8fe84) [0x55d5e9e14e84] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0xb839f) [0x55d5e9e3d39f] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x29a) [0x55d5e9e419fa] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(command_process_cell+0x2fc) [0x55d5e9e23a1c] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(channel_tls_handle_cell+0x333) [0x55d5e9e030d3] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0xa773f) [0x55d5e9e2c73f] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(connection_handle_read+0x990) [0x55d5e9df0500] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0x707ee) [0x55d5e9df57ee] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fb82bb5f5a0] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(do_main_loop+0x105) [0x55d5e9df6b25] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_run_main+0x1225) [0x55d5e9de4545] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_main+0x3a) [0x55d5e9de193a] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(main+0x19) [0x55d5e9de14b9] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fb82a3b32e1] (on Tor 0.4.1.6 ) Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x55d5e9de150a] (on Tor 0.4.1.6 ) Nov 21 00:18:02.000 [notice] Tor 0.4.1.6 opening log file. Nov 21 00:18:02.605 [notice] We compiled with OpenSSL 101000bf: OpenSSL 1.1.0k 28 May 2019 and we are running with OpenSSL 101000cf: OpenSSL 1.1.0l 10 Sep 2019. These two versions should be binary compatible. Nov 21 00:18:02.606 [notice] Tor 0.4.1.6 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0l, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2. <...> Nov 21 00:18:03.000 [notice] Bootstrapped 0% (starting): Starting Nov 21 00:18:07.000 [warn] Incorrect ed25519 signature(s) Nov 21 00:18:10.000 [notice] Starting with guard context "default" <...> Should I open a ticket?

2 1

Strange OpenPGP behavior during key import under Debian Buster
by Olaf Grimm 18 Nov '19

18 Nov '19

Hello! I repeatedly try to install Tor under Debian Buster and fail again at key import. With the last system I found the solution by activating the "Experimental repos" under Debian. This time it didn't work and I kept looking. Before repair: ... 2019-11-15 21:18:33 (294 KB/s) - ‘A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc’ saved [19665/19665] gpg: no valid OpenPGP data found. gpg: Total number processed: 0 My procedure: I opened the key copied from the Tor website and found at the end of the key the spelling ... sGsEejVHxvX7/iOE3rM= =47bK -----END PGP PUBLIC KEY BLOCK----- I changed the last line intuitively with an editor to ... sGsEejVHxvX7/iOE3rM==47bK -----END PGP PUBLIC KEY BLOCK----- and saved it. Afterwards the import worked! gpg2 --import ./A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc gpg: key EE8CBC9E886DDD89: 36 signatures not checked due to missing keys gpg: key EE8CBC9E886DDD89: public key "deb.torproject.org archive signing key" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found gpg2 --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add - OK I have no explanation! Best regards! Olaf Translated with www.DeepL.com/Translator

3 3

BEREC draft duidelines on the implementation of the open Internet regulation
by Vasilis 17 Nov '19

17 Nov '19

Hi, For those of you that operate or administer relays in EU networks, this may be important for you to follow or/and provide comments on the draft. The Body of European Regulators for Electronic Communications (BEREC) has started a public consultation on the draft of BEREC guidelines on the implementation of the open Internet regulation, you can find more info here: https://berec.europa.eu/eng/document_register/subject_matter/berec/public_c… The public consultation is open until: 28 November 2019 Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Public key: https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF…

1 0