- tor-relays - lists.torproject.org

Windows Relay Setup
by William Pate 13 Jul '19

13 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] 08 Jul '19

08 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 08 Jul '19

08 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 08 Jul '19

08 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

Tor Performance on Xen vs KVM
by Conrad Rockenhaus 30 Jun '19

30 Jun '19

Hello, I’m just curious on how people feel about relay performance on Tor nodes running on Xen vs KVM. I’ve noticed on Xen I have increased network performance and I do like the improved modular architecture of Xen vs KVM (right now I’m working on an experimental OpenStack w/ XCP-ng environment). I was wondering if any others on the list had experience running high performance Tor nodes on Xen and KVM and have a preference for one over the other… I’m just trying to compare and contrast here. Of course, I built a XCP-ng pool with a compute VM, then I have a regular KVM compute instance running under the Openstack framework. Thanks, Conrad Rockenhaus http://www.greyponyit.com/

1 0

BridgeDB currently up but non-functional?
by Rick Huebner 28 Jun '19

28 Jun '19

Hi, all. While skimming /r/tor on Reddit I saw a couple of posts saying they hadn't been able to get any usable bridges for several days, and thought I'd check into it. I downloaded & installed a fresh copy of the Windows TBB 8.5.1 and had it ask for bridges via Moat, and received 2 (not 3?) obfs4 bridge lines. Here's the Tor log from the "copy to clipboard" button that popped up on the TBB "connecting" dialog when it stalled at about 3/4th of the progress bar: 6/19/19, 10:46:16.735 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.735 [NOTICE] Switching to guard context "bridges" (was using "default") 6/19/19, 10:46:16.735 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.736 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.736 [NOTICE] Opening Socks listener on 127.0.0.1:9150 6/19/19, 10:46:16.736 [NOTICE] Opened Socks listener on 127.0.0.1:9150 6/19/19, 10:46:16.736 [NOTICE] Renaming old configuration file to "C:\Downloads\Tor Browser 8.5.1 - Copy\Browser\TorBrowser\Data\Tor\torrc.orig.1" 6/19/19, 10:46:23.608 [NOTICE] Bootstrapped 5%: Connecting to directory server 6/19/19, 10:46:23.611 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 6/19/19, 10:46:24.558 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection 6/19/19, 10:46:24.748 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus 6/19/19, 10:46:24.954 [NOTICE] new bridge descriptor 'eldritchworld' (fresh): $<BRIDGE 1 FINGERPRINT REDACTED>~eldritchworld at <BRIDGE 1 IP REDACTED> 6/19/19, 10:46:25.589 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:26.781 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus 6/19/19, 10:46:28.291 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. 6/19/19, 10:46:28.482 [NOTICE] Bootstrapped 40%: Loading authority key certs 6/19/19, 10:46:28.997 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services. 6/19/19, 10:46:28.997 [NOTICE] Bootstrapped 45%: Asking for relay descriptors for internal paths 6/19/19, 10:46:28.997 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6440, and can only build 0% of likely paths. (We have 100% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.275 [NOTICE] Bootstrapped 50%: Loading relay descriptors for internal paths 6/19/19, 10:46:29.463 [NOTICE] The current consensus contains exit nodes. Tor can build exit and internal paths. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.514 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.514 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Bootstrapped 57%: Loading relay descriptors 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.684 [NOTICE] Bootstrapped 64%: Loading relay descriptors 6/19/19, 10:46:30.684 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.873 [NOTICE] Bootstrapped 73%: Loading relay descriptors 6/19/19, 10:46:30.873 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.873 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.937 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.969 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:44.618 [WARN] Proxy Client: unable to connect to <BRIDGE 2 IP REDACTED> ("general SOCKS server failure") It looks like bridge 1 (eldritchworld) gave me bad/incomplete relay info which prevented making circuits, and then Tor failed to connect to the fallback bridge 2 at all. Checking Relay Search, it shows that eldritchworld is a normal healthy-looking bridge that's been up for months with plenty of connections and data being transferred, so I don't know what's wrong there. So, since the Moat bridges didn't work, I went to the BridgeDB request web page to try that. Clicking the "Just give me bridges" button and doing the captcha returned "Uh oh, spaghettios! There currently aren't any bridges available... Perhaps you should try going back and choosing a different bridge type!". What, no vanilla bridges available at all? Seriously? (As a side note, cutesy errors are pretty annoying when things are failing. Just sayin'.) And as usual the Metrics page still shows about 1000 bridges, so something's badly broken. I know the new bridgedb release doesn't give out ORports if there's a secure PT offered, but last I checked the majority of bridges were just vanilla, so surely there must be enough to put some into whichever bridge pool ring my request was pulled from. I then tried asking for obfs4 bridges instead, and it did give me one (again, not 3?). With another fresh install of the TBB and entering that bridge line, the log shows: 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] Switching to guard context "bridges" (was using "default") 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] Opening Socks listener on 127.0.0.1:9150 6/19/19, 10:59:43.912 [NOTICE] Opened Socks listener on 127.0.0.1:9150 6/19/19, 10:59:43.912 [NOTICE] Renaming old configuration file to "C:\Downloads\Tor Browser 8.5.1 - Copy\Browser\TorBrowser\Data\Tor\torrc.orig.1" 6/19/19, 10:59:50.761 [NOTICE] Bootstrapped 5%: Connecting to directory server 6/19/19, 10:59:50.762 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 6/19/19, 11:00:11.767 [WARN] Proxy Client: unable to connect to <BRIDGE 3 IP> ("general SOCKS server failure") So this 3rd bridge also failed to connect at all. With the Moat and website requests both returning bad/dead bridges (if any), the last thing to try was the email request channel. I sent "request bridges" to bridges(a)torproject.org and it replied back "Here are your bridges: None, None, None". Well, okay then. Maybe if I try again later, which should give me different bridges to use? According to the bridgedb config file checked into the git repo, the rotation periods for the Moat and website bridge pool query positions are both 3 hours. So I waited 3.5 hours and tried those tests again on another fresh TBB install copy, and both Moat and the website returned back to me the exact same bridges as before, which then failed in the same ways as before. Maybe the running server isn't using the checked-in config settings? Waiting another 8 hours (11.5 total since the first try), Moat gave me the same first bridge but finally a different second bridge (still not 3), but that one also failed to connect at all with the same "general SOCKS server failure". The website still claims there are no vanilla bridges available at all, and gives me back the same single obfs4 choice as before, which still won't connect at all. I don't know if it's the link between the bridge authority and the bridgdb server, or the new bridgedb release that just came out or what, but something's badly broken and the bridgedb appears to be pretty much useless right now. My test environment is very standard, just Windows 10 Pro using only IPV4 from a normal US ISP (Frontier FIOS near Portland, OR) with no proxy, running a fresh copy of the current TBB build. The TBB works fine if I don't use a bridge or if I manually enter the bridge info for a private bridge relay I temporarily set up, and I have no other internet issues. Could someone else check if they see similar problems? Other people should supposedly get different bridgedb results pulled from the other bridge pool rings, but even if it's somehow only affecting one pool ring, that's like 20-25% of the bridgedb's users left with no viable results. Looking at the Metrics site I don't see any drop in current bridge user counts (actually it's in an uptrend, along with all tor user counts lately) but I'd assume most bridge users already have working bridge lines cached, so this would only affect new users or those whose old choices have gone down, but both of those categories will only grow with time.

2 5