- tor-relays - lists.torproject.org

Limiting Tor Relay To Run On Google Cloud VPS
by Keifer Bly 20 Jul '19

20 Jul '19

Hi all, So a while back I was trying to run a tor relay via Google Cloud VPS but it was costing quite a bit. However, I was chatting with them, and I found out that as long as the relay generates a maximum of 4.9 GB per month and less than 2 million connections, it won't cost anything. I am wondering how to configure these limitations in tor? Thanks all. It's a small relay I know. --Keifer

4 4

Call for setting up new obfs4 bridges
by Philipp Winter 20 Jul '19

20 Jul '19

Hi everyone, BridgeDB is running low on obfs4 bridges and often fails to provide users with three bridges per request. Besides, we recently fixed a BridgeDB issue that could get an obfs4 bridge blocked because of its vanilla bridge descriptor: <https://bugs.torproject.org/28655> We therefore want to encourage volunteers to set up new obfs4 bridges to help censored users. Over the last few weeks, we have been improving our obfs4 setup guide which walks you through the process: <https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4…> The guide provides instructions for Debian, Ubuntu, CentOS, RHEL, OpenSUSE, FreeBSD, and OpenBSD. If you're running into any issues with the guide, please let us know! Finally, once you set up an obfs4 bridge, make sure that both your ORPort *and* your obfs4 port are reachable. Tor currently only tests the reachability of its ORPort. We set up a service that allows you to test the reachability of your obfs4 port: <https://bridges.torproject.org/scan/> Thanks for keeping the Tor network healthy by running relays and bridges! Thanks, Philipp

9 15

Windows Relay Setup
by William Pate 14 Jul '19

14 Jul '19

I'm interested in hosting a Windows-based relay, if anyone can point me to a good tutorial. I've tried the most common ones.

3 2

What fraction of Tor’s DNS traffic goes to Google and Cloudflare?
by nusenu 13 Jul '19

13 Jul '19

https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google… > 60.05% of the tor network’s exit capacity uses a resolver which is > located in the same autonomous system as the exit relay itself (that > includes localhost) which is recommended to minimize the path > between exit relay and its resolver. Lets aim to increase this > fraction to above 80%. > > If you are an exit operator and want to help reach this goal you can > use this list to verify you are not using Google or Cloudflare > resolvers. https://gist.github.com/nusenu/e6eec32679cc64ffe3e24d2b9367a931 > The Tor Relay Guide has instructions for setting up a > local DNS resolver. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DNSonExitRelays -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

3 2

What rules for a fallback dir - the compiled-in fingerprint, a flag from the authorities or both?
by Toralf Förster 13 Jul '19

13 Jul '19

I do just wonder how a client decides whether/when fallback dir is to be used, especially when the *.inc file changed. -- Toralf PGP C4EACDDE 0076E94E

1 0

tor_bug_occured_(): This line should not have been reached
by [REDACTED] 09 Jul '19

09 Jul '19

Hey guys, my relay 79E683340B80676DCEB029E48FBD36BC66EBDA1E told me: Jul 06 15:22:34.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 150515 circuits rejected, 16 marked addresses. 0 connections closed. 104 single hop clients refused. Jul 06 16:23:25.000 [warn] tor_bug_occurred_(): Bug: ../src/core/or/channeltls.c:1111: channel_tls_handle_cell: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111. Stack trace: (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x562903c4faa6] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x562903c4b1c0] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x562903ad571a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x9a16a) [0x562903af916a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x99d) [0x562903ac318d] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x69ebe) [0x562903ac8ebe] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f469cdbf9ba] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f469cdc0537] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xb0) [0x562903aca290] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x562903ab80d5] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x562903ab530a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x562903ab4ec9] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f469c6a109b] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x562903ab4f1a] (on Tor 0.3.5.8 ) Jul 06 21:22:34.000 [notice] Heartbeat: Tor's uptime is 12 days 6:00 hours, with 5113 circuits open. I've sent 2802.42 GB and received 2781.10 GB. Jul 06 21:22:34.000 [notice] Circuit handshake stats since last time: 13801/13801 TAP, 169020/169020 NTor. Its anyway a little bit strange because this is the only relay i have which never deleted his logfiles since i set it up and where i can not change the language of the operating system. I think its related to the host system but i never really thought about because it seems to work fine. Something i should do now?

2 1

Re: [tor-relays] Call for setting up new obfs4 bridges
by nottryingtobelame＠protonmail.com 09 Jul '19

09 Jul '19

Hello, I successfully ran an obfs4 bridge about a year ago that saw moderate traffic. After a few months, the traffic died off until I was consistently seeing 0 clients. I wiped the keys, got a new IP address, and started a new bridge. The 2nd bridge saw 0 clients, over several months. I finally wiped it again and started a 3rd bridge. Same thing, 0 clients for several months. My 4th bridge, which I took down last night, was up for just shy of 3 months with 0 clients. Before I took it down, I tested using https://bridges.torproject.org/scan/ and confirmed the ports were reachable. While I was not able to test the previous iterations, I setup the port forwarding for each of them for both the OR Port and the Ext OR Port that it randomly assigned. I won't be able to grab a new IP address this time, but I'm starting the bridge up again with new ID keys and new ports. Is it normal for bridges to see no traffic, and if they're not seeing any, should I keep them online?

2 1

Testing the accessibility of my obfs4 bridge
by nottryingtobelame＠protonmail.com 09 Jul '19

09 Jul '19

I plugged my bridgeline into Tor Browser on Windows, and connected successfully. I put it into Orbot on Android and also connected successfully. But when I put it into the new Tor Browser for Android, I am unable to connect. The logs from Tor Browser are pasted here: https://pastebin.com/cF5bwRH1. Any idea why one client would be failing to connect? Thanks in advance.

2 1

ExoneraTor results may be incomplete between April 25 and 30, 2019 and during other periods
by Karsten Loesing 08 Jul '19

08 Jul '19

Hello relay operators, it turns out that our exit scanner had an issue between April 25 and 29, 2019 and that ExoneraTor results may be incomplete during this time. Some context, taken from the ExoneraTor page: https://metrics.torproject.org/exonerator.html "The ExoneraTor service maintains a database of IP addresses that have been part of the Tor network. It answers the question whether there was a Tor relay running on a given IP address on a given date. ExoneraTor may store more than one IP address per relay if relays use a different IP address for exiting to the Internet than for registering in the Tor network, and it stores whether a relay permitted transit of Tor traffic to the open Internet at that time." Now, if somebody looks up their exit IP address during the time between April 25 and 29, 2019, their relay won't be listed in the results. It will still be included with the IP address that it used for registering at the directory authorities, but not with its exit IP address. I looked through the archive of exit lists and found similar downtimes of 18 hours or longer which would have the same effect: Gap of 19 hours between 2011-09-10T00:05:00 and 2011-09-10T19:28:46. Gap of 23 hours between 2011-12-21T01:21:19 and 2011-12-22T00:23:36. Gap of 111 hours between 2012-02-07T02:33:16 and 2012-02-11T18:07:47. Gap of 26 hours between 2013-03-07T15:16:50 and 2013-03-08T17:17:55. Gap of 156 hours between 2013-03-14T09:29:25 and 2013-03-20T22:03:41. Gap of 19 hours between 2015-10-09T14:13:37 and 2015-10-10T09:57:26. Gap of 18 hours between 2018-02-02T18:27:54 and 2018-02-03T13:06:09. Gap of 122 hours between 2019-04-25T13:13:19 and 2019-04-30T15:40:21. Gap of 21 hours between 2019-05-25T19:04:43 and 2019-05-26T16:09:23. We're working on adding a notice to ExoneraTor results in case a lookup falls into one of these periods, but that will take us some time. https://trac.torproject.org/projects/tor/ticket/31071 Sorry for any confusions caused by this! All the best, Karsten

1 0

obfs4 relay lost stable flag
by tor 01 Jul '19

01 Jul '19

Hi I've been running an obfs4 bridge for about a month. My hashed fingerprint is: E120A0492F789F5367EAD84C64F92EE279018F98 I recently lost the stable flag. Not sure why. Any thoughts? thanks matt

3 2