- tor-relays - lists.torproject.org

Unutilized bandwidth
by Alec Larsen 01 Aug '19

01 Aug '19

Hello, I've only recently joined this list, so I apologise in advance if this is not the appropriate place for my question. For the past month, I have been operating an exit node ( 89094DFA4158C7A1583EC3A332CDCBC74A28CC0E ) from UnitedIX in Chicago, IL, US. The server has a dedicated gigabit port, and I had hoped to be able to relay around 200 TB of traffic per month, but for some reason my advertised bandwidth has been hovering at just 12 MiB/s since the first few days. The server itself is an older Supermicro PfSense server with a Xeon E3-1270v3 at 3.5ghz and 32gb of RAM. It is currently running the latest stable release of FreeBSD (12.0p7) and Tor (0.4.0.5). As far as I can tell, the machine is mostly idle: * The Tor process is the most active, and I've yet to see it go above 5% CPU. * Memory usage is under 1.5gb. * Running `speedtest-cli` (even to different servers using the `--server` option) consistently gives 600mbps+ in both directions to most destinations. * There's nothing interesting in `dmesg` or the debug logs. Does anyone have suggestions for what the bottleneck here might be? I'm happy to share more details about my configuration if that would be helpful. Thank you in advance for any help that you are willing to provide! I think Tor provides a lot of value, and I would like to provide as much bandwidth as I can to the network. -- Alec

6 7

Cherryservers (formerly balticservers) account terminated for exit relay
by Chris Kerr 31 Jul '19

31 Jul '19

I just heard from the hosting provider cherryservers.com that they are terminating my account (after 2.5 years) where I run the exit relay "ostwaldripening" (46.166.162.53), because they no longer wish to host tor exit nodes. I tried to create an account on trac.torproject.org to edit the "GoodBadISPs" wiki page, but the spam blocking stopped me from doing so.

5 4

Re: [tor-relays] Windows Relay Setup
by William Pate 31 Jul '19

31 Jul '19

Hi! Well, I certainly expected far more snarky responses. :) Thank you for the links. I'll check them out and, if I get it to work, maybe write up a guide for others. Thank you! William ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, July 14, 2019 1:44 AM, Barton Bruce <barton.bruce(a)gmail.com> wrote: > > > William, > > On 7/11/2019 6:58 PM, William Pate wrote: > > > 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. > > > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > There used to be a VIDALIA (sp?) kit that could simply be downloaded and > run on a windows machine. I then worked for an ISP/CLEC and had lots of > bandwidth so ran Vidaalia on a 64 bit Windows 7 Ultimate machine on my > desk at work. > > I never did hear why something had changed at the tor project so that > stopped working, but do remember a rude snippy condescending reply from > someone on the mailing list so I lost interest. > > I did get the head Tor guy from the Central Square Cambridge office of > TOR to come speak at a local networking group's monthly meeting we held > at a MicroSlush faclity in Burlington, MA and it was well received by a > packed audience. I think he now has left TOR and works for some ISP. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus

4 3

exit operators: overall DNS failure rate above 5% - please check your DNS resolver
by nusenu 30 Jul '19

30 Jul '19

Dear Exit relay operators, first of all thanks for running exit relays! One of the crucial service that you provide in addition to forwarding TCP streams is DNS resolution for tor clients. Exit relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase significantly due to some major exit operators apparently having DNS issues and we would like to urge you to visit Arthur's "Tor Exit DNS Timeouts" page that shows you the DNS error rate for exit relays: https://arthuredelstein.net/exits/ (the page is usually updated once a day) Please consider checking your DNS if your exit relay consistently shows a non zero timeout rate - and make sure you run an up to date tor version. If you are an exit operator but have no (or no working) ContactInfo, please consider updating that field in your torrc so we can reach you if something is wrong with your relay. kind regards nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

11 15

Question about Bridges Bandwidth Authority
by s7r 28 Jul '19

28 Jul '19

Hello, I'd like to know more details about how exactly the bridge bandwidth authority works, and if we use the "weight" of each bridge for anything. For example, I have setup 5 obfs4 bridges, with the exact very same hardware resources and all on the same network speed of course. One of them gets used by clients (say 20-50 unique clients every 6 hours or so) while the rest of 4 are not used at all. This usage is not a concern for me, as its known bridges take time until they get used, depending on which bucket they have been assigned and etc. So I assume it's OK at this particular point in their lifetime to be unused by any client. But what I am curious about is, when I search them on RelaySearch, the used one has a measured bandwidth of over 2 MiB/s (and has the fast flag) while other 3 unused ones have bandwidths of between 50 and 60 KiB/s (these also have the fast flag) and there is one last one which is also not used and has a bandwidth of less than 10 KiB/s that does not have the fast flag. (Fast flag missing is also not my problem, I am just mentioning it as a side detail). Now I know for sure those values are not at all in according to the real environment. Each bridge should be at least capable of 3 MiB/s even if all 5 are used at the same time at their full speeds. Actually I have simulated this, it's not just theoretical. Is there anything related to usage, so that the bridge bandwidth authority only measures the used bridges? What could have cause such big discrepancy in my particular case, any ideas? Also, do we use the weight of each bridge in order to determine how much % probability it has to be served to a request in the bucket that is part of, or we don't use bridge weights for anything at all? Thanks!

3 4

Relay authority
by torjoy 26 Jul '19

26 Jul '19

Hi, this is my first post here. I'm running 3 bridges in brazil (maybe one of them becomes a middle-relay), so I want to know what we need here to have some bridge authority for example here in south america. Is too much different from a normal relay? I've already see the "authorithative flags" for torrc but dont made any changes. I think something more should be done and is not so easy. Best regards.

2 3

Re: [tor-relays] Call for setting up new obfs4 bridges
by dmz21＠ziggo.nl 22 Jul '19

22 Jul '19

> On July 19, 2019 at 1:44 PM Ben Riley <blades1000(a)gmail.com> wrote: > > > To follow up my previous email, I found the "Firewall" app and I've > manually opened 9051 & 8531 in that, and when I tested those via the online > port checking tools, they are now open. > > Restarted TOR (sudo systemctl restart tor) and the logs show it > bootstrapped to 100% and stated the ORPort 9051 is now reachable. > TOR did its bandwidth self-test.....done. > > Should that now be working ok? Yes, the logs look good. I think the ORPort indeed needs to be reachable for a bridge. You could try testing your own bridge using Tor Browser [1] or a Tails DVD [2]. Or wait a few hours (or weeks for the graphs) and look up your bridge on Tor Relay Search [3]. [1] https://www.torproject.org/download/ [2] https://tails.boum.org/ [3] https://metrics.torproject.org/rs.html# > Log now reads: > > Jul 19 21:31:43 ben-OptiPlex-755 Tor[8779]: Bootstrapped 10% (conn_done): > > Connected to a relay > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 14% (handshake): > > Handshaking with a relay > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 15% > > (handshake_done): Handshake with a relay done > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 75% > > (enough_dirinfo): Loaded enough directory info to build circuits > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 90% > > (ap_handshake_done): Handshake finished with a relay to build circuits > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 95% > > (circuit_create): Establishing a Tor circuit > > Jul 19 21:31:45 ben-OptiPlex-755 Tor[8779]: Guessed our IP address as > > 158.140.206.75 (source: 217.182.196.67). > > Jul 19 21:31:46 ben-OptiPlex-755 Tor[8779]: Bootstrapped 100% (done): Done > > Jul 19 21:31:46 ben-OptiPlex-755 Tor[8779]: Now checking whether ORPort > > 158.140.206.75:9051 is reachable... (this may take up to 20 minutes -- > > look for log messages indicating success) > > Jul 19 21:31:49 ben-OptiPlex-755 Tor[8779]: Self-testing indicates your > > ORPort is reachable from the outside. Excellent. Publishing server > > descriptor. > > Jul 19 21:32:14 ben-OptiPlex-755 Tor[8779]: New control connection opened. > > Jul 19 21:33:05 ben-OptiPlex-755 Tor[8779]: Your network connection speed > > appears to have changed. Resetting timeout to 60s after 18 timeouts and 129 > > buildtimes. > > Jul 19 21:33:07 ben-OptiPlex-755 Tor[8779]: Performing bandwidth > > self-test...done. > > > > On Fri, Jul 19, 2019 at 8:41 PM Ben Riley <blades1000(a)gmail.com> wrote: > > > Thanks for that. So I tried as you suggested and edited (gedit) the torrc > > file, replacing the obfs4 from 443 to 8531. > > I also added a port forward for that port on my router. > > Restarted TOR and the log file shows that it made a circuit (Bootstrapped > > 100%). > > I can now run nyx and see that TOR is trying to make connections. > > As per the log below, it seems that ORPort 9051 is unreachable (which is > > true according to a port checker) > > Though I've got the following ports forwarded on the router 9050, 9051, > > 443 & 8531 - 9001 is NOT forwarded though. > > > > Now the log says this: > > > >> Jul 19 19:53:58 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.969 [notice] > >> Tor 0.4.0.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, > >> Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.970 [notice] > >> Tor can't help you if you use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.990 [notice] > >> Read configuration file "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.990 [notice] > >> Read configuration file "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.997 [notice] > >> Based on detected system memory, MaxMemInQueues is set to 2862 MB. You can > >> override this by setting MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Configuration was valid > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Tor 0.4.0.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, > >> Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Tor can't help you if you use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Read configuration file "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Read configuration file "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.214 [notice] > >> Based on detected system memory, MaxMemInQueues is set to 2862 MB. You can > >> override this by setting MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening Socks listener on 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened Socks listener on 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening OR listener on 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened OR listener on 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening Extended OR listener on 127.0.0.1:0 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Extended OR listener listening on port 36399. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened Extended OR listener on 127.0.0.1:36399 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Tor 0.4.0.5 running on Linux > >> with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and > >> Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Tor can't help you if you > >> use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Read configuration file > >> "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Read configuration file > >> "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Based on detected system > >> memory, MaxMemInQueues is set to 2862 MB. You can override this by setting > >> MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening Socks listener on > >> 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened Socks listener on > >> 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening OR listener on > >> 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened OR listener on > >> 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening Extended OR listener > >> on 127.0.0.1:0 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Extended OR listener > >> listening on port 36399. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened Extended OR listener > >> on 127.0.0.1:36399 > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Parsing GEOIP IPv4 file > >> /usr/share/tor/geoip. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Parsing GEOIP IPv6 file > >> /usr/share/tor/geoip6. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Configured to measure > >> statistics. Look for the *-stats files that will first be written to the > >> data directory in 24 hours from now. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Your Tor server's identity > >> key fingerprint is 'MelbTORbridge 9F19251CEE17B1E05084898D164F0544CCB095DD' > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Your Tor bridge's hashed > >> identity key fingerprint is 'MelbTORbridge > >> E4AF099DA5946A6D6EA65DC55B517D3F9B12D0ED' > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Bootstrapped 0% (starting): > >> Starting > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Starting with guard context > >> "default" > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Signaled readiness to systemd > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Bootstrapped 5% (conn): > >> Connecting to a relay > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Registered server transport > >> 'obfs4' at '[::]:8531' > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opening Socks listener on > >> /run/tor/socks > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opened Socks listener on > >> /run/tor/socks > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opening Control listener on > >> /run/tor/control > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opened Control listener on > >> /run/tor/control > >> Jul 19 19:54:17 ben-OptiPlex-755 Tor[15449]: Bootstrapped 10% > >> (conn_done): Connected to a relay > >> Jul 19 19:54:17 ben-OptiPlex-755 Tor[15449]: Bootstrapped 14% > >> (handshake): Handshaking with a relay > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 15% > >> (handshake_done): Handshake with a relay done > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 20% > >> (onehop_create): Establishing an encrypted directory connection > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 25% > >> (requesting_status): Asking for networkstatus consensus > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 50% > >> (loading_descriptors): Loading relay descriptors > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Guessed our IP address as > >> 158.140.206.75 (source: 185.103.110.144). > >> Jul 19 19:54:20 ben-OptiPlex-755 Tor[15449]: I learned some more > >> directory information, but not enough to build a circuit: We have no recent > >> usable consensus. > >> Jul 19 19:54:21 ben-OptiPlex-755 Tor[15449]: I learned some more > >> directory information, but not enough to build a circuit: We're missing > >> descriptors for 1/2 of our primary entry guards (total microdescriptors: > >> 5382/6384). > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 75% > >> (enough_dirinfo): Loaded enough directory info to build circuits > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 90% > >> (ap_handshake_done): Handshake finished with a relay to build circuits > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 95% > >> (circuit_create): Establishing a Tor circuit > >> Jul 19 19:54:27 ben-OptiPlex-755 Tor[15449]: Bootstrapped 100% (done): > >> Done > >> Jul 19 19:54:27 ben-OptiPlex-755 Tor[15449]: Now checking whether ORPort > >> 158.140.206.75:9051 is reachable... (this may take up to 20 minutes -- > >> look for log messages indicating success) > >> Jul 19 19:55:35 ben-OptiPlex-755 dbus-daemon[3325]: [session uid=1000 > >> pid=3325] Activating service name='org.gnome.Calculator.SearchProvider' > >> requested by ':1.262' (uid=1000 pid=8482 comm="/usr/bin/gnome-shell " > >> label="unconfined") > >> Jul 19 19:55:36 ben-OptiPlex-755 dbus-daemon[3325]: [session uid=1000 > >> pid=3325] Successfully activated service > >> 'org.gnome.Calculator.SearchProvider' > >> Jul 19 19:55:42 ben-OptiPlex-755 nautilus[15604]: Could not get mtime for > >> 'file:///home/ben/.cache/tracker/meta.db': Error when getting information > >> for file “/home/ben/.cache/tracker/meta.db”: No such file or directory > >> Jul 19 19:55:43 ben-OptiPlex-755 bijiben-shell-s[15603]: Could not get > >> mtime for 'file:///home/ben/.cache/tracker/meta.db': Error when getting > >> information for file “/home/ben/.cache/tracker/meta.db”: No such file or > >> directory > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: Error opening > >> database: Could not open sqlite3 > >> database:'/home/ben/.cache/tracker/meta.db': unable to open database file > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: > >> tracker_sparql_query_exec_sql_cursor: assertion 'iface != NULL' failed > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: ___lambda11_: > >> assertion 'cursor != NULL' failed > >> Jul 19 19:55:49 ben-OptiPlex-755 Tor[15449]: New control connection > >> opened. > >> Jul 19 19:55:56 ben-OptiPlex-755 org.gnome.bijiben.SearchProvider[3325]: > >> Unable to load location /home/ben/.local/share/bijiben: Error opening > >> directory '/home/ben/.local/share/bijiben': No such file or directory > >> Jul 19 20:03:43 ben-OptiPlex-755 org.gnome.Shell.desktop[8482]: Window > >> manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a > >> timestamp of 0 for 0x6e00084 (torrc (/et) > >> Jul 19 20:14:38 ben-OptiPlex-755 Tor[15449]: Your server ( > >> 158.140.206.75:9051) 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. > >> > > > > > > On Fri, Jul 19, 2019 at 6:34 PM < > > dmz121(a)ziggo.nl> wrote: > > > >> > >> > On July 19, 2019 at 6:36 AM Ben Riley <blades1000(a)gmail.com> wrote: > >> > > >> > > >> > Hi, > >> > > >> > Thanks for the reply. Yes, I ran that command way back at the start. I'm > >> > assuming I don't have to run it every time the machine reboots or > >> updates? > >> > I ran it again this morning and it made no difference. > >> > > >> > Ah logs, you say that like I know where those are :P > >> > When I run sudo tail /var/log/tor/log - I get nothing. > >> > I found the Logs app and run that to get all the system logs - way too > >> much > >> > stuff and I couldn't move it to here, so I found this command (Google) > >> cat > >> > /var/log/syslog | grep tor -i and got the following (I think I've > >> included > >> > 2 set of attempts to boot up): > >> > > >> > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Starting with guard context > >> > > "default" > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Signaled readiness to > >> systemd > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bootstrapped 5% (conn): > >> > > Connecting to a relay > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Server managed proxy > >> > > encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: > >> > > permission denied) > >> > >> I ran (and keep running) into the same problem (but on Debian), even > >> after the fix suggested below. > >> Could you please try an unused port above 1024, like 8531? That resolved > >> this issue for me. > >> > >> hope this helps and kind regards. > >> > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Managed proxy at > >> > > '/usr/bin/obfs4proxy' failed the configuration protocol and will be > >> > > destroyed. > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: tor_assertion_failed_(): > >> Bug: > >> > > ../src/feature/client/transports.c:1836: > >> managed_proxy_stdout_callback: > >> > > Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on > >> Tor > >> > > 0.4.0.5 ) > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bug: Assertion > >> mp->conf_state > >> > > == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at > >> > > ../src/feature/client/transports.c:1836. Stack trace: (on Tor 0.4.0.5 > >> ) > >> > >> (removed rest of log) > >> > >> > > >> > > >> > > >> > On Fri, Jul 19, 2019 at 1:12 AM Philipp Winter <phw(a)torproject.org> > >> wrote: > >> > > >> > > On Thu, Jul 18, 2019 at 12:50:34PM +1000, Ben Riley wrote: > >> > > > Then I saw the above email about being a bridge and thought, fine, > >> I'll > >> > > > configure it to be a bridge and help out someone. > >> > > > Tried to do it via the docker/script method, but soon realised that > >> was > >> > > > outside my skill level (hey stop laughing! :P) > >> > > > >> > > Did you run into any specific issues? If you had troubles following > >> the > >> > > guide, I'm gonna blame the guide. > >> > > > >> > > > Setting ORPort to 443 as suggested. I forwarded that port on the > >> > > > router and then tested it, but it said it was closed. So I thought > >> my > >> > > > router was playing up. I checked a few other ports using online > >> tools > >> > > > and a few of them were closed. I forwarded a new another port to > >> some > >> > > > other software on another machine and that worked?! So I realised > >> the > >> > > > ports are open on the router but closed on the ubuntu machine. I've > >> > > > played around with all the settings, changed by torrc file to a > >> really > >> > > > basic one of: > >> > > > >> > > To run obfs4 on port 443, you will have to run the following command, > >> to > >> > > allow obfs4proxy to bind to port 443: > >> > > > >> > > sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy > >> > > > >> > > If you did that already, it would be helpful to see your logs. > >> > > > >> > > Cheers, > >> > > Philipp > >> > > _______________________________________________ > >> > > tor-relays mailing list > >> > > tor-relays(a)lists.torproject.org > >> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > > >> > _______________________________________________ > >> > tor-relays mailing list > >> > tor-relays(a)lists.torproject.org > >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > >

3 3

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

19 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 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

An easy self-DoS and how to avoid it
by j4c4l4 28 Jun '19

28 Jun '19

Hi there, I have been operating a non-exit relay and a bridge for about one week now. I discovered by chance a quite silly self-DoS which could be triggered by using a NIDS (Network Intrusion Detection System) on relays. I don't know if it is known, but I thought it was worth reporting it here. In many Linux distributions, several NIDSs come with a default policy that blocks all the traffic from offending IPs after they have reached a threshold score. The offending IPs are normally put into a separate firewall chain/table that DROPs all the traffic originating from them, and then re-enabled after a period that could vary between 30 minutes and a few hours (again, depending on the config). Now, this could be potentially used to periodically shut down relays. In fact, an attacker could perform something as simple as an ssh login scan *through tor*, which is among the "attacks" monitored by most of the NIDS out there. But since the login attempts appear to originate from the tor exit relay, this effectively flags *the exit* as an "offending" host, and triggers the corresponding firewall rule (which is normally a blind "DROP", to save on rule processing). Once an exit node is flagged as "offending" and put in the firewall rule, any traffic between the relay and the exit node is effectively forbidden, until the firewall rule is removed or the tables flushed. If performed on a large scale, this can potentially shut down all the relays which run a NIDS with such policy on ssh logins. The same is true for other simulated attacks on other protocols (but ssh monitoring and blind DROPs are so much common to be the ones of most concern, maybe). I don't know how many relays run a NIDS (I suspect several do, actually), but it would be better to be aware of this potential self-DoS attack. The easy solution (apart from not using any IDS on relays) is to make sure that all the incoming traffic to the ORPort is always accepted, e.g. introducing an ad-hoc firewall first rule that accepts all TCP stuff from the ORPort, before processing NIDS-managed rules. Sorry if this was known already, but I couldn't find anything related by looking at the recent topics in the ML archives, and I thought it coud be useful to share. Regards

1 0

Best practice for tor-exit node when I switch internet providers?
by Chris Dagdigian 28 Jun '19

28 Jun '19

Hello, I've been running a tor exit node in the US since 2014 when I paid way too much for a comcast business internet circuit that came with static IPs and a TOS that allowed me to run servers at home. It looks like I'm going to switch providers in a month or so as there is a fiber service I can get with symmetric bandwidth, the static IP count I want and theoretically also a TOS that is also amenable to server hosting. What is the best practice if I want to keep my tor exit going but switch upstream carriers and IP addresses? I'm guessing this is going to trip a bunch of tor monitoring alerts if I just bring the server up at a new IP address. Should I change the nickname? Totally wipe and reinstall tor itself? The goal is to bring back the same exit node but not set off any alarms when the exit node with the same IP for many years suddenly shows up with a new address. -Chris

2 1

torrelays have no bandwith
by TorGate 28 Jun '19

28 Jun '19

Hi to all, i have issues with my 3 relays, there is no bandwith ?! i have not changed the config only updatet the tor software. In nyx can i see there are smal bandwith connections 1-100 kbs. All 3 relays have a 5mbit up/down connection. https://metrics.torproject.org/rs.html#search/torgate

3 3

Interesting Reddit Post for Tor Relay Operators on Verizon FiOS (Verizon blocks Verizon.com on Tor Relay IP Addresses Including Non-Exit Relays)
by neel＠neelc.org 26 Jun '19

26 Jun '19

Hi tor-relays@ mailing list, If you are running Tor relays on FiOS, or run Tor relays and are considering joining FiOS, here's an interesting Reddit Post: Title: Verizon blocks Verizon.com on Tor Relay IP Addresses (Including Non-Exit Relays) URL: https://www.reddit.com/r/privacy/comments/c5whh5/verizon_blocks_verizoncom_… -Neel Chauhan === https://www.neelc.org/

1 0

TCP SACK PANIC type kernel vulnerabilities: logging some packets
by tor＠t-3.net 25 Jun '19

25 Jun '19

As of last week there wasn't a new kernel out for our relay's distro, so I implemented an IPTables-based mitigation in our relay as such: -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j LOG --log-prefix "TCP_SACK_PANIC: " -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP Over the weekend we logged hits to this rule. I checked a few of the source hosts, and they were not relays at least as they are listed in https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1 . I'll pull the rule out once the kernel is patched, but yeah. Things that make you go hmm.

2 1

Re: [tor-relays] Tor memory leak (0.3.5.7)?
by starlight.2018q2＠binnacle.cx 25 Jun '19

25 Jun '19

Hi, No leaks. The VM has 1GB, very light for moderate busy relay. Should be 4GB, perhaps 3DB would do. Settings should include: AvoidDiskWrites 1 DisableAllSwap 1 MaxMemInQueues 1024MB # perhaps 1536MB My relays run about 800MB to 1.2GB. A nice way to view memory usage is with egrep '^Vm' /proc/$(cat /var/run/tor.pid)/status which might show something like VmPeak: 871696 kB VmSize: 710152 kB VmLck: 710148 kB VmHWM: 810872 kB VmRSS: 649328 kB VmData: 492052 kB VmStk: 93 kB VmExe: 4704 kB VmLib: 104724 kB VmPTE: 1044 kB Notice that current VmSize usage is less than VmPeak, indicating that memory was release by glibc malloc. Tor consumes substantial skbuf memory in the kernel, which accounts for some of the difference in reported size for VmRSS and VmSize and total memory consumption.

3 2