- tor-relays - lists.torproject.org

Re: [tor-relays] longclaw BWauth is broken -- no measurements since 7/22
by starlight.2015q2＠binnacle.cx 25 Jul '15

25 Jul '15

Realized not everyone monitors this list so I opened a Trac ticket: https://trac.torproject.org/projects/tor/ticket/16667 At 11:19 7/25/2015 -0700, you wrote: >Interesting. Thanks starlight for the head's up! I'm not >aware of any known issues with longclaw right now >so looping in its operator. > > >On Sat, Jul 25, 2015 at 10:09 AM, ><starlight.2015q2(a)binnacle.cx> wrote: >> Subject says it. >> >> Thought it was strange that its measurement >> of my relay has not been moving. Pulled the >> vote history and grep'ed a dozen relay >> measurements and none of them have changed. >>

1 0

longclaw BWauth is broken -- no measurements since 7/22
by starlight.2015q2＠binnacle.cx 25 Jul '15

25 Jul '15

Subject says it. Thought it was strange that its measurement of my relay has not been moving. Pulled the vote history and grep'ed a dozen relay measurements and none of them have changed.

2 1

Re: [tor-relays] How to Run High Capacity Tor Relays
by Green Dream 24 Jul '15

24 Jul '15

Pardon the thread necromancy, but I'm wondering if this document ever made its way off this mailing list and onto a blog? Or perhaps there is some other modern doc covering this topic? I've recently setup a relay on a Gb/s fiber connection, and am struggling to understand how to optimize performance. It's not clear 5 years later which if any of the tweaks listed below are still relevant. I'm running a modern debian-based system. Thanks in advance. > After talking to Moritz and Olaf privately and asking them about their > nodes, and after running some experiments with some high capacity > relays, I've begun to realize that running a fast Tor relay is a > pretty black art, with a lot of ad-hoc practice. Only a few people > know how to do it, and if you just use Linux and Tor out of the box, > your relay will likely underperform on 100Mbit links and above. > In the interest of trying to help grow and distribute the network, my > ultimate plan is to try to collect all of this lore, use Science to > divine out what actually matters, and then write a more succinct blog > post about it. > However, that is a lot of work. It's also not totally necessary to do > all this work, when you can get a pretty good setup with a rough > superset of all of the ad-hoc voodoo. This post is thus about that > voodoo. > Hopefully others will spring forth from the darkness to dump their own > voodoo in this thread, as I suspect there is one hell of a lot of it > out there, some (much?) of which I don't yet know. Likewise, if any > blasphemous heretic wishes to apply Science to this voodoo, they > should yell out, "Stand Back, I'm Doing Science!" (at home please, not > on this list) and run some experiments to try to eliminate options > that are useless to Tor performance. Or cite academic research papers. > (But that's not Science, that's computerscience - which is a religion > like voodoo, but with cathedrals). > Anyway, on with the draft: > > == Machine Specs == > First, you want to run your OS in x64 mode because openssl should do > crypto faster in 64bit. > Tor is currently not fully multithreaded, and tends not to benefit > beyond 2 cores per process. Even then, the benefit is still marginal > beyond just 1 core. 64bit Tor nodes require about one 2Ghz Xeon/Core2 > core per 100Mbit of capacity. > Thus, to fill an 800Mbit link, you need at least a dual socket, quad > core cpu config. You may be able to squeeze a full gigabit out of one > of these machines. As far as I know, no one has ever done this with > Tor, on any one machine. > The i7's also just came out in this form factor, and can do > hyperthreading (previous models may list 'ht' in cpuinfo, but actually > don't support it). This should give you a decent bonus if you set > NumCPUs to 2, since ht tends to work better with pure integer math > (like crypto). We have not benchmarked this config yet though, but I > suspect it should fill a gigabit link fairly easily, possibly > approaching 2Gbit. > At full capacity, exit node Tor processes running at this rate consume > about 500M of ram. You want to ensure your ram speed is sufficient, > but most newish hardware is good. Using on this chart: > > https://secure.wikimedia.org/wikipedia/en/wiki/List_of_device_bandwidths#Me… > you can do the math and see that with a dozen memcpys in each > direction, you come out needing DDR2 to be able to push 1Gbit full > duplex. > As far as ethernet cards, the Intel e1000e *should* be theoretically > good, but they seem to fail at properly irq balancing across multiple > CPUs on recent kernels, which can cause you to bottleneck at 100% CPU > on one core. At least that has been Moritz's experience. In our > experiments, the RTL-8169 works fine (once tweaked, see below). > > == System Tweakscript Wibbles and Config Splatters == > First, you want to ensure that you run no more than 2 Tor instances > per IP. Any more than this and clients will ignore them. > Next, paste the following smattering into the shell (or just read it > and make your own script): > # Set the hard limit of open file descriptors really high. > # Tor will also potentially run out of ports. > ulimit -SHn 65000 > # Set the txqueuelen high, to prevent premature drops > ifconfig eth0 txqueuelen 20000 > # Tell our ethernet card (interrupt found from /proc/interrupts) > # to balance its IRQs across one whole CPU socket (4 cpus, mask 0f). > # You only want one socket for optimal ISR and buffer caching. > # > # Note that e1000e does NOT seem to obey this, but RTL-8169 will. > echo 0f > /proc/irq/17/smp_affinity > # Make sure you have auxiliary nameservers. I've seen many ISP > # nameservers fall over under load from fast tor nodes, both on our > # nodes and from scans. Or run caching named and closely monitor it. > echo "nameserver 8.8.8.8" >> /etc/resolv.conf > echo "nameserver 4.2.2.2" >> /etc/resolv.conf > # Load an amalgam of gigabit-tuning sysctls from: > # http://datatag.web.cern.ch/datatag/howto/tcp.html > # http://fasterdata.es.net/TCP-tuning/linux.html > # http://www.acc.umu.se/~maswan/linux-netperf.txt > # http://www.psc.edu/networking/projects/tcptune/#Linux > # and elsewhere... > # We have no idea which of these are needed yet for our actual use > # case, but they do help (especially the nf-contrack ones): > sysctl -p << EOF > net.ipv4.tcp_rmem = 4096 87380 16777216 > net.ipv4.tcp_wmem = 4096 65536 16777216 > net.core.netdev_max_backlog = 2500 > net.ipv4.tcp_no_metrics_save = 1 > net.ipv4.tcp_moderate_rcvbuf = 1 > net.core.rmem_max = 1048575 > net.core.wmem_max = 1048575 > net.ipv4.ip_local_port_range = 1025 61000 > net.ipv4.tcp_synack_retries = 3 > net.ipv4.tcp_tw_recycle = 1 > net.ipv4.tcp_max_syn_backlog = 10240 > net.ipv4.tcp_fin_timeout = 30 > net.ipv4.tcp_keepalive_time = 1200 > net.netfilter.nf_conntrack_tcp_timeout_established=7200 > net.netfilter.nf_conntrack_checksum=0 > net.netfilter.nf_conntrack_max=131072 > net.netfilter.nf_conntrack_tcp_timeout_syn_sent=15 > net.ipv4.tcp_keepalive_time=60 > net.ipv4.tcp_keepalive_time = 60 > net.ipv4.tcp_keepalive_intvl = 10 > net.ipv4.tcp_keepalive_probes = 3 > net.ipv4.ip_local_port_range = 1025 65530 > net.core.netdev_max_backlog=300000 > net.core.somaxconn=20480 > net.ipv4.tcp_max_tw_buckets=2000000 > net.ipv4.tcp_timestamps=0 > vm.min_free_kbytes = 65536 > net.ipv4.ip_forward=1 > net.ipv4.tcp_syncookies = 1 > net.ipv4.tcp_synack_retries = 2 > net.ipv4.conf.default.forwarding=1 > net.ipv4.conf.default.proxy_arp = 1 > net.ipv4.conf.all.rp_filter = 1 > net.ipv4.conf.default.send_redirects = 1 > net.ipv4.conf.all.send_redirects = 0 > EOF > # XXX: ethtool wibbles > # You may also have to tweak some parameters with ethtool, possibly > # also enabling some checksum offloading or irq coalescing options to > # spare CPU, but for us this hasn't been needed yet. > > == Setting up the Torrc == > Basically you can just read through the stock example torrc, but there > are some as-yet undocumented magic options, and options that need new > defaults. > # NumCPUs doesn't provide any benefit beyond 2, and setting it higher > # may cause cache misses. > NumCPUs 2 > # These options have archaic maximums of 2-5Mbyte > BandwidthRate 100 MB > BandwidthBurst 200 MB > > == Waiting for the Bootstrap and Measurement Process == > Perhaps the most frustrating part of this setup is how long it takes > for you to acquire traffic. If you are starting new at an ISP, I would > consider only 200-400Mbit for your first month. Hitting that by the > end of the month may be a challenge, mostly because their may be dips > and total setbacks along the way. > The slow rampup is primarily due to limitations in Tor's ability to > rapidly publish descriptor updates, and to measure relays. > It ends up taking about 2-3 days to hit an observed bandwidth of > 2Mbyte/sec per relay, but it can take well over a week or more (Moritz, do > you have a better number?) to reach 8-9Mbyte/relay. This is for an > Exit node. A middle node will likely gather traffic slower. Also once > you crash, you lose it. This bug is about that issue: > https://trac.torproject.org/projects/tor/ticket/1863 > There is also a potential dip when you get the Guard flag, as our load > balancing formulas try to avoid you, but no clients have chosen you > yet. Changes to the authority voting on Guards in Tor 0.2.2.15 should > make this less drastic. It is also possible that your observed > bandwidth will be greater than without it. However, it will still take > up to 2 months for clients to choose you as their new Guard. > > == Running temporary auxiliary nodes == > One way to shortcut this process and avoid paying for bandwidth you > don't use is to spin up a bunch of temporary nodes to utilize the CPU > and quickly gather that easy first 2MB/sec of observed bandwidth. > But you need the spare IPs to do this. > > == Monitoring == > Personally, I prefer console-based options like nload, top, and > Damian's arm (http://www.atagar.com/arm/) because I don't like the > idea of running extra services to publish my monitoring data to the > world. > Other people have web-based monitoring using things like munin and > mrtg. It would be nice to get a script/howto for that too. > > == Current 1-Box Capacity Record == > Our setup has topped at 450Mbit, but averages between 300-400Mbit. We > are currently having uptime issues due to heat (melting, poorly > ventilated harddrives). It is likely that once we resolve this, we > will continually increase to our CPU ceiling. > I believe Moritz and Olaf also push this much capacity, possibly a bit > more, but with less nodes (4 as opposed to our 8). I hear Jake is also > ramping up some Guard nodes (or maybe I didn't? Did I just betray you > again Jake?) > > == Did I leave anything out? == > Well, did I? > > -- > Mike Perry > Mad Computer Scientist > fscked.org evil labs

8 11

Running a relay in the Netherlands
by TorOps 24 Jul '15

24 Jul '15

Hello, I am about to move to the Netherlands and will, as part of the move, decommission the server my relay is currently running on. I'd like to be able to continue to help, though, so I wonder how the legal climate is for Tor relays and/or exit nodes in the Netherlands? On a related topic, how smart/efficient/possible is it to run a relay/exit on a Raspberry Pi? Thanks for any info. -- Regards, StairNetTor Operator

6 7

The ultimate DMCA culprit
by I 24 Jul '15

24 Jul '15

2 1

[warn] Content-Length is less than zero; it looks like someone is trying to crash us
by Toralf Förster 23 Jul '15

23 Jul '15

4 6

Fwd: Tor family graphs
by Virgil Griffith 23 Jul '15

23 Jul '15

Hello tor-relays@ We are still working on your nice relay incentive as and part of that we've been looking at how to partition relays into different families with it's not 100% obvious what that groupings should be. For those that are interested in the family connections, I have some pretty PDFs for you. I present three graphs of all Tor relays (nodes) with at least one family connection (edge). (1) only symmetric edges shown (black) -- http://dl.dropbox.com/u/3308162/sym.pdf (2) only asymmetric edges shown (red) -- http://dl.dropbox.com/u/3308162/asym.pdf (3) both symmetric (black) and asymmetric (red) shown -- http://dl.dropbox.com/u/3308162/both.pdf Notes: * A node is colored red if and only if it is the origin of an asymmetric connection. Ergo, every red node has at least one red edge, and vice-versa. * Blue edges are self-connections. I presume the Tor directory authorities should be excluding should these edges from the consensus---unless you all like being cute? Unfortunately you cannot click to see where you are in the graph. Hopefully in a future version you'll be able to click-around using D3.js or some such. -V

4 8

OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by nusenu 22 Jul '15

22 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Pascal, what do you think of changing OpenBSD's tor rc script to require perfect process matches when sending signals to them instead of the current "kill everything that starts with..." approach? I've put tor-relays on CC so people can speak up if this change is not desired or breaks anyone's environment - I believe it fixes them. Problem: /etc/rc.d/tor stop might kill all (including unrelated) tor instances instead of the intended daemon only. /etc/rc.d/tor start might never start the intended daemon if another tor instance is already running (rc_check believes tor is already running). /etc/rc.d/tor restart might kill all tor instances and starts only one. references: http://article.gmane.org/gmane.os.openbsd.misc/222896 One line "patch" for /etc/rc.d/tor to address this issue: (tested with and without custom daemon_flags) 8a9,10 > pexp="${daemon}${daemon_flags:+ ${daemon_flags}}$" > (this line is a complete copy from rc.subr with the addition of one char: $ ) thanks, nusenu https://github.com/nusenu/ansible-relayor/issues/40 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViSx3AAoJEFv7XvVCELh0y8UQAJgb6JVbKde/xf79YJJr8LW1 t+Rji8A5zZ9VsjcW4Pguf/OZsQEN3MEIkjzTM3kw0q9S8CPnDbF3IYOaZj4ewYkX 8OoNmHfFbcQCC0YCJBlbUJMBtNJqi8pg7qRY4o+qY9KKa9ekUhPer7kzUt4N1A+T an4z44lh3ytAcehyFxo6hpDGZHHGGsACEIql9Rav6v+DPCBSJnCZsmlT0OeTeV5k 5WEy9nTVzdkX4mKs1xXv8YJFggCrb1uur3q91/5ZGhpKADfRj6T+1i/9622Bcki9 17ADc4ZI73dP3ZelKvpZ+FXhaiZLn6tugdj2dcqnXU8Zras6jKToupFi2nB8xfTV f70qSdkMP6WOJReCP+KTAGHiCkapyoc9V+8569iZIjUXuD7GbbSpP6I1rOoqSLYH rao6WpqHVfSMQ5jCaECHBbZY62qBhHH83B/um3nG+WXvvWDPpzjkbEx56RxH3UUo yZ4naGenbxQzCXsGXhEOAmUkJjSmW+Hw75EyObBLAp00+Q8zAXkHnFOqRGbRuxdl IKqAYsfGNLr7kPBvz9pxfnOJMfyIBDQ2P2WNyKXvYLME3wKbYMazVxd7cXzmAV5g QthMuFJ/JhWYI9Lb1U+IQq7LOX+pEWU6u/L2xqjTDj7VMn4UF1WZ6UHhnaLMAotZ lfiTKPnopA62t+X05ztR =ysgm -----END PGP SIGNATURE-----

3 5

Re: [tor-relays] Running a relay in the Netherlands
by Jan Hendrik den Besten 22 Jul '15

22 Jul '15

> Date: Tue, 21 Jul 2015 00:13:19 +0200 > From: t0reo(a)t0reo.eu > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Running a relay in the Netherlands > > Hello All ! > > About running a relay in the NL, what host company would you guys > recommend ? > > I also have that idea of running first a relay then an exit node, and > would like some basic information or recommendation about host > providers, like price /month, bandwidth included, satisfaction or > quality, level of tor friendliness, whatever... > > Thx for any help you can provide, > tOreo I have my node running here in The Netherlands at UPC, now merged with Ziggo. I contacted them once: back then they did not have a problem running even an exit node. BR, JH

4 3

[Relay] Hibernation Reset
by Tor Operator 22 Jul '15

22 Jul '15

Hi gents, I rencetly had one of my relay fall into hibernation. It seems that simply restarting the service doesn't change the hibernation status since Tor is still thinking that the BW limits have been overrun. Is the proper method to reset the status of the node is simply to delete the "state" file in "/var/lib/tor/". For now, I just set back to 0 the "AccountingBytesReadInInterval" and "AccountingBytesWrittenInInterval" counters and the node was able to wake up but that doesn't seem like a very elegant way to do it. Thanks,

2 3

BWauth's / TorFlow seem better
by starlight.2015q2＠binnacle.cx 22 Jul '15

22 Jul '15

Over the last week it seems to me that some improvement has gone into TorFlow and the BWauths are performing better. In particular the weightings calculated by each BWauth have stabilized and become less erratic. Several relays in the same region of a large network as my relay are now showing a roughly matching pattern of ascending measures, from smallest to largest: longclaw, gabelmoo, maatuska, moria1. One would expect this but it was not true in the past. One fast relay I watch, 'pixelminer' had a tendency to be yanked from one extreme to another (e.g. 10k to 120k and back) and now has a placid consensus running in the middle of the range (still apparent in the {presumably stabilized} component values).

1 1

Boosting throughput with own DNS resolvers
by Tim Semeijn 21 Jul '15

21 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Recently I noticed my Tor Exit nodes were showing nameserver errors in the tor log and I decided to set up two private DNS resolvers (pdns-recursor). Since I use those I have seen an increase of traffic throughput on my Exit nodes to approx. 150%. I feel I am finally utilizing the resources available. All bigger Tor relay operators will probably already do it this way, but as I myself have long been using Google DNS or other privacy-aware DNS resolvers on my nodes I just wanted to throw this out in the open. How many of you are already using private DNS resolvers for your nodes? Any feedback/ideas about this? - -- Tim Semeijn Babylon Network pgp 0x5B8A4DDF -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJVrAzLAAoJEIZioqpbik3fmkcP/R5DXaKoVHUY6SjiSJi0n8ug 6NMF2KTXNP3f7vFbuzjWdqdo4Hfj2Zj6SyKc+i99/pJFiISQiGsMfeWjwdGGqaxR hlCNxYAsnV2kFd8UK435kOv2LclPFDMPjFk9OLr+DDQ8ZFmkpF80+95fqwzKaPr0 XtltMNBDxO8uCC4zsNYpT2BlO4EwhMTB5/79lNJ44MlWaSaPd6BAqoDfExyBjZfV v7bvQxqSNxF5jZvoNBRw1/t1jc8AXZF7UxkkR62ff7cBiQsDo16QK4sRcDTNRziM y5fm8Tt9W+19gsf0CNPo7lj7j/T7yHj3gClBi7TmhSxsIO7ylpeuX6L9hsAkzOJm o9TMgkO11T6h0e5EiCJh6P0ov21pqUJ61ScN/D0qiHVJC42UM/diGqVFgev3AT3u NImaA7IPUXvDC+Z+EQulnBP4XdIuukozU/4DJFF4x5tDhyTTXhCInrVsaMB4rOIU lLfQLZiCCC39uxIBs+xvS+rN1+wAVq4VH4Wbd5w4tH7e2Ic0BLBaI71z00RoTiF/ i8TK5IDP+gfykBemXtAcZeyyTkuzf6fFZg3NKfCPGbOqvpLEGEk26Mp8ANv+csTb HQXbmFtPX/SUhxm2zdMzA2uq8gzHOllxmEKriYyon499ZfCImbmBU+1kTKo+v2p7 lOMSGXcjkCVgAwtnZNKw =YekJ -----END PGP SIGNATURE-----

5 6

Re: [tor-relays] Simplifying ExoneraTor
by Joshua Lee Tucker 20 Jul '15

20 Jul '15

Hi guys, I've made some simple (improvements?) changes to the ExoneraTor page - I've basically made the "about" section a sticky footer (no JS) and spaced the content a little better. I've tested it across Firefox/Chrome/Safari/iOS and it looks good on all of them. Maybe we could also add some information about the expected IP and date formats in the whitespace, too. The updated version can be found at: http://tucker.wales/tor/exonerator/ Please let me know what you think. Kind Regards, Joshua Lee Tucker @tuckerwales

2 9

Simplifying ExoneraTor
by Karsten Loesing 20 Jul '15

20 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello relay operators, Julius and I have been working on a design mockup for the ExoneraTor service for the past few months and would want to hear what you think about this: https://people.torproject.org/~karsten/volatile/exonerator-mockup/ The main idea behind this redesign was to simplify the existing ExoneraTor service by omitting technical details (e.g., Tor descriptor contents) and removing mostly unused features (e.g., parsing detailed exit policies). Please take a look at the design mockup, maybe compare it to the existing ExoneraTor service, and let us know your thoughts. Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVlOrvAAoJEJD5dJfVqbCr3LoH/RbAW7FdSG53/rAm/FSE1AI+ mJP/c+Uost5iaymfg1n5nAYVMYSNgg3BanItVbRHBd4rdtdcTz0ZhmUDvol5+jHA eUbWwL5M1SmOZdpNGDxx5fGkm7DEcnSFnVMPqN9gFKtm+zSBtNeJ9bcNiktwL7WW VrpElBu3P9N+YLBemN5W9/TYEjEx6q1Mx4t22qij7xBdRfVJKS1XqwwntRSapbLo Y2TCt/rVG2fD7rMIO3vNidCg8eaA4ax7qXJcABAx1+lsPFHoKwCG0nmNZ6FP+Ips XSbk+FHApAK+txzS16NVwdtOpm/YyCQIVaIQ8EjIyKBSlSJDGWRXwgHOBhglliE= =4/zE -----END PGP SIGNATURE-----

11 48

Exit Policy Information != ExitPolicy reject
by fatal 19 Jul '15

19 Jul '15

Hello, I got an abuse report from Webiron requesting me to block a /24 subnet. Accordingly I added "ExitPolicy reject xxx.xxx.xxx.0/24:*" to my torrc file. Looking at the Exit Policy Information at atlas and torstatus xxx.xxx.xxx.0/24 doesn't get listed. This worries me a bit. Am I missing something? Thanks!

3 4

Catch 22 pay, set-up and be banned
by I 19 Jul '15

19 Jul '15

3 2

Naive question about consensus weight
by Jonathan Baker-Bates 17 Jul '15

17 Jul '15

I've been running an exit node for a number of years without incident, so I tend not to look at its state very much. I'm also not very technically knowledgeable about Tor. However, I notice from Atlas that from January 1st, the exit probability of my server dropped dramatically and has stayed that way together with the observed bandwidth being always a small fraction of the speed I advertise: https://atlas.torproject.org/#details/3612C429C29F698DEAB5072C75E2D700893D0… So I'm curious as to whether there's anything I can do to bring my consensus weight up, apart from just ensuring continuous uptime. That's not often under my control though, since reboots for kernel updates etc. come quite regularly. Apologies if this a common question, but some initial searches on the subject turned up rather too much information for me to understand! Jonathan

4 4

0.2.6.10 cell fullness
by Austin Holiday 15 Jul '15

15 Jul '15

Hi, has anyone experience any performance differences between 0.2.6.10 vs 0.2.6.9? The logs are different so perhaps it is hard to compare. It seems my connection is not very active. Does the lack of cell fullness suggest an issue?. Log from 0.2.6.10: Jul 14 23:40:33.000 [notice] Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 277 kB and received 6.27 MB. Jul 14 23:40:33.000 [notice] Average packaged cell fullness: 40.544%. TLS write overhead: 9% Log from 0.2.6.9: Jul 13 19:19:39.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 1 v3 connections, and 16483 v4 connections; and received 83 v1 connections, 1576 v2 connections, 2 v3 connections, and 34108 v4 connections. Jul 14 01:19:39.000 [notice] Heartbeat: Tor's uptime is 14 days 17:59 hours, with 1 circuits open. I've sent 2.07 GB and received 2.19 GB. Jul 14 01:19:39.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 0/0 NTor. Thanks. --Austin

1 0

relay bangs into rock; falls off cliff; recovers
by starlight.2015q2＠binnacle.cx 15 Jul '15

15 Jul '15

I've seen this about three times, maybe four. Anyone have any idea what's going on? Version 0.2.6.10 on Linux. Showed up in 0.2.5.x and 0.2.4.x earlier. 1) seems to happen only one time per relay start after a few hours up to a couple of days; weeks or months between occurrences 2) might be happening after dynamic config change but not certain (did this time, one hour later) 3) might related to / triggered by client activity--was simply browsing regular Internet at the time 4) main thread appears to bog-down, but some traffic continues 5) log messages tied to event :20:26 : Failed to find node for hop 0 of our path. Discarding this circuit. :20:26 : Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. :20:29 : Failed to find node for hop 0 of our path. Discarding this circuit. :20:32 : Failed to find node for hop 0 of our path. Discarding this circuit. :20:32 : Tried for 122 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit) :20:34 : Failed to find node for hop 0 of our path. Discarding this circuit. :21:06 : last message repeated 14 times :21:45 : last message repeated 23 times 6) for several minutes, all outbound client connection attempts show <fail> in Vidalia; NEWNYM has no effect 7) (5) and (6) imply a rate-limit by the guard but AFIK there was no burst of circuit request that would trigger this 8) client functionality recovers in something like five minutes (awhile after relay forwarding traffic knotch ends) 9) no increase in memory consumption, so apparently no buffering backlog 10) WAN clean, no glitches I suppose I should submit a bug report, but I just finished with a bug-from-hell and am in no mood to work another one, especially since the problem is rare and not fatal.

1 2

nf_conntrack: falling back to vmalloc.
by Toralf Förster 14 Jul '15

14 Jul '15

Starting with 12th ojf June I do get at my tor relay a lot of sslog entries like : Jul 14 14:35:49 tor-relay kernel: [68591.883586] nf_conntrack: falling back to vmalloc. Jul 14 14:35:49 tor-relay kernel: [68591.884749] nf_conntrack: falling back to vmalloc. Jul 14 14:41:11 tor-relay kernel: [68913.618544] nf_conntrack: falling back to vmalloc. Now I'm wondering if this is by any chance related to Tor ? -- Toralf, pgp key: 872AE508 0076E94E

1 0

Re: [tor-relays] relay bangs into rock; falls off cliff; recovers
by starlight.2015q2＠binnacle.cx 14 Jul '15

14 Jul '15

Circuit count seems to have mostly reverted to normal: Tor's uptime is 4 days 18:00 hours, with 6691 circuits open. . . on 3990 channels found an object overview: http://www.kmcg3413.net/aman/index.py?page=tor_internals.txt [connection] [channel] [circuit] [stream]

1 0

relay bangs into rock; falls off cliff; recovers
by starlight.2015q2＠binnacle.cx 13 Jul '15

13 Jul '15

I've seen this about three times, maybe four. Anyone have any idea what's going on? Version 0.2.6.10 on Linux. Showed up in 0.2.5.x and 0.2.4.x earlier. 1) seems to happen only one time per relay start after a few hours up to a couple of days; weeks or months between occurrences 2) might be happening after dynamic config change but not certain (did this time, one hour later) 3) might related to / triggered by client activity--was simply browsing regular Internet at the time 4) main thread appears to bog-down, but some traffic continues 5) log messages tied to event :20:26 : Failed to find node for hop 0 of our path. Discarding this circuit. :20:26 : Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. :20:29 : Failed to find node for hop 0 of our path. Discarding this circuit. :20:32 : Failed to find node for hop 0 of our path. Discarding this circuit. :20:32 : Tried for 122 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit) :20:34 : Failed to find node for hop 0 of our path. Discarding this circuit. :21:06 : last message repeated 14 times :21:45 : last message repeated 23 times 6) for several minutes, all outbound client connection attempts show <fail> in Vidalia; NEWNYM has no effect 7) (5) and (6) imply a rate-limit by the guard but AFIK there was no burst of circuit request that would trigger this 8) client functionality recovers in something like five minutes (awhile after relay forwarding traffic knotch ends) 9) no increase in memory consumption, so apparently no buffering backlog 10) WAN clean, no glitches I suppose I should submit a bug report, but I just finished with a bug-from-hell and am in no mood to work another one, especially since the problem is rare and not fatal.

1 0

OVH: the biggest and fastest growing autonomous system
by nusenu 13 Jul '15

13 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, OVH is by far the biggest AS on the tor network, in terms of consensus weight (>12%), guard probability (>15%), middle propability (>14%) and in the top 3 by exit probability(>7%). Here are some AS stats for June 2015, that show which ASes added most bandwidth/CW to the tor network. This shows that OVH is not only the biggest AS but also the fasted growing AS: +-------------------------------------+---------+-------------------+ | as_name | new_FPs | added_CW_fraction | +-------------------------------------+---------+-------------------+ | OVH SAS | 98 | 2.129 | | Digital Ocean, Inc. | 44 | 0.936 | | Internet Assigned Numbers Authority | 23 | 0.911 | | ONLINE S.A.S. | 23 | 0.594 | | SOFTplus Entwicklungen GmbH | 4 | 0.512 | | STRATO AG | 8 | 0.274 | | Contabo GmbH | 9 | 0.200 | | LDeX Connect LTD | 5 | 0.200 | | myLoc managed IT AG | 7 | 0.178 | | Core-Backbone GmbH | 2 | 0.160 | | PlusServer AG | 9 | 0.141 | | PCextreme B.V. | 1 | 0.119 | | Hetzner Online AG | 30 | 0.113 | | ISPpro Internet KG | 3 | 0.113 | | United Gameserver GmbH | 4 | 0.107 | | BlazingFast LLC | 12 | 0.101 | | WorldStream | 19 | 0.092 | +-------------------------------------+---------+-------------------+ new_FPs: number of relays (identified by fingerprint) that were first seen in June 2015 and were still running at some point during the last 7 days added_CW_fraction aggregated CW fraction of relays identified in the new_FPs column If you want to help stop this trend, and make the tor network more diverse, choose non-top 10 ASes when adding relays (10 is an arbitrary number). You can use compass 'group by AS' feature to find out about the top X ASes: https://compass.torproject.org/ or if that is unavailable/not working, Thomas White's compass instance: https://compass.thecthulhu.com If you know in advance that you are running guards/exits only you can sort the table by guard or exit probability by clicking on the column name to find out about crowded guard/exit ASes. thanks for running relays, nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVmFbuAAoJEFv7XvVCELh02FIP/i4ncGP/MDvAehhq+VZraZ/N b7u3L6ZM43zhgLjL4SJQc2mAEfAE9Nf/OCfjAIAdnwr1z+dt0nJZU6ei2RfS045I AwwLsjMZ3hO2l4LLifZcbAGSD0ROd5Il2+Nj90lrBBOmSddjsR/aw5BucDTQqDs2 FTWeezoJEXQcWRnwPPkGwT0bS0vrU4WnXG26lJu3SmUdJyXHEfPHFHiVNKHn04up 0L2fMH7XcFbLkeLyZ2tlhJn+L0asFBch6J5XJMWAyGy1B3uwJDPGpbo4k8eCsRS+ VguyJoEZ1GnVlofx08oX2HbUUhenP9YHtGwRk1joIO8KLR5d5CKNEK3CCkMrqH87 B1uxV/apZV6Bse1H/bMOFxGmCgOgheyRrHPTibDlp5cDyYPysF3piC4jAVs7CSSY 42UD1R53XcLSToVKfCAcH1zCbxa4DpX5Lx+/X0Wb+037Azect6nlUw9lh7edM6Ih jCl8ZVKek2kFg5EHgTVvKCtn9kyW7jXNlbVZ/HP8tO7OlpRIxgZJ46yuwX8nNDzh P9VZ2J33AiPu/G4mcM/MwbhysDBIOsieYP4547gSXSLLnWuQhOteV4y1H5edDneW nbl3WrYA2qDlBfwgJFjvu+jkG3Xbws25RLyesHUvT60i/gXG+sunv1J7JrX6JgW6 D+3xHeWye6kGkEfZgIzr =eeGk -----END PGP SIGNATURE-----

1 1

the effect of bw auth location on relay selection
by nusenu 09 Jul '15

09 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (split from 'Qualities of a good relay' thread) > I run a relay in Japan on a gigabit connection, but nobody cares > too much, since (I assume) bwauths aren't anywhere near Japan and > do not get good speeds to it, they give it a low weight, and as a > result it doesn't see a lot of use. Lets say the BW auth is located on your LAN and gives you "1GBit/s" measurements, that would increase the likelihood that clients choose you but if your 1GBit/s uplink is limited to your city/country and the international uplink is eg. 100MBit/s than the measurement value alone wouldn't help much for non-JP partners, no? At least clients in JP would have an measurement value that matches reality better. Actually it would indeed be fancy to have location-aware measurement clients. Clients in Asia would consider asian* bw auth measurements to be more important than measurements from non-asian bw auths, but this presumably performance improvement would likely reduce anonymity properties as clients in JP would more likely choose guards in JP. Attackers targeting JP clients would than be in a better position because they could start guards in JP only and have a higher likelihood of being chosen as guards by a JP client (their targets). performance vs. privacy trade-off as usual. ..and the bw auth system is currently (hopefully) undergoing other changes to prevent recent problems from happening again. I just saw that JP has a guard probability of 0%. (at the same time JP is in the top 10 countries of directly connecting tor users.) Out of 132 relays in JP, there are only 3 guard relays and these 3 are exits as well so they are used as exits only. Your relatively fresh jp relay had the guard flag once for a short period of time, but lost it again - probably due to the last restart. So maybe its usage will rise once it is done with the bootstrapping phase and had the guard flag over a few months. btw: Thanks for running the biggest declared family (by consensus weight) on the tor network! *) there is no bw auth in Asia in reality, current locations: +----------+-----------+---------------+---------+ | nickname | city_name | region_name | country | +----------+-----------+---------------+---------+ | moria1 | Cambridge | Massachusetts | us | | gabelmoo | Erlangen | Bavaria | de | | longclaw | NULL | NULL | us | | maatuska | NULL | NULL | se | +----------+-----------+---------------+---------+ -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVi948AAoJEFv7XvVCELh09EcP/jAL0Gnh9yFpo444pGIipCej TH+hGT+4bNp0irXFVlWk88kBrJ90LR/by7fSwJizEoKaqD9KV5bXuOtl9BdRN+7J nQIcR7rZ6tkMXa71VZX9fG3dvg+GjqbcciMA4tutc3fnXhPScmfLnd1lAZSKoG+M Mt7HzEluW+FZO30ixmPDojVEt2xHC87ntOlYA6rbVBarsXGC2GGP6FDhETOrTftN 0nodbUjIom0W0OyYKPhq/cnS3rckdZDctAKmJDSr7uvmWNWQRiF1eLxUoB96DopQ YthkoErJcv5cuPlwuu1iWvK0fxYen7XNF+hl1bezaRW8aRDBL6dVJDX0JhwAhSzS oKkfkOeuiFiihXbM7dRXwTN9z+wZSIuk3fuJfom+ALrS7Dbu0CER6t5Ynxdbcu8h f7qoroSIK9X0aQhc2RQBXlabkNywLKnsMV+DMJOa5NEHCt5WU9JOwFZax0mGumpj WEzoWEoGR95Z4uFQ5fx9TBmronAlKAHU9C+q0sO0FQSUyHL8WKkBBuWjr3wMSMU7 73+z+LIydb80DpXJ4EurxsF/23MsOiuUk6tUl5NnGMQ8DcQeUDPAtOrIPds6/JZm T6mgBWvB1VQugkoM5pNM24ybEEgp85PtnXpRY/Su4FhpTHMB/2RarGp3GTZw954a /KRXEZb3p9ntEnDnXXoc =S/g8 -----END PGP SIGNATURE-----

2 2

Re: [tor-relays] More consensus weight problems
by Speak Freely 08 Jul '15

08 Jul '15

Rah rah rah... Emailed Aaron directly by accident. Here's the email: Hello, First of all, I love Tor. I love Tor Browser, and I love running relays. When the problems are solved, I will most likely spin up more relays. I'm leaving my fastest relay running, as a method of checking the status for myself. The rest have already started to expire, and within the next week or so most of the other ones will have expired as well. I'm going to try tor-dev-alpha 2.7.1 and change fingerprints, as per a suggestion from s7r, seeing as how I have nothing to lose. I just wish the bwauths could scan relays based off previous relative consensus weights... If this particular relay was at 27000, it should be higher on the list to check compared to another one I have that is at 487. My one relay was blazing fast with thousands of connections, my other is painfully useless with dozens, but my fastest one lost its consensus while the slowest one kept it's consensus. It just seems silly. That being said, I don't know how/if the bwauths scan in any order or just willy-nilly, (that's not entirely true, I know it's segmented to some degree as I recall reading a blog post about how it's chopped up) but... I'd be much less upset if my best relays worked and my worst relays didn't. More complaining... bleh. One thing I would like to point out though... it appears... These problems have at least a casual relationship with MyFamily. One group of MyFamily is completely done - all of them stuck at 20. Another group of MyFamily is working happily. I've been doing some tests over the past few months trying to understand why I keep having problems, and one thing has consistently popped up... MyFamily. As one of MyFamily lost consensus, another family gained consensus back on or around the same time. Yes, especially nusenu, I know I'm supposed to have it all configured to be under 1 MyFamily... But in a way I'm glad I didn't, as the casual relationship I see really could only be seen having done what I did. I say casual because I have no proof of causation. But... it is interesting. If no one else has experienced similar problems, then I'd chock it up to a completely unexpected unrelated set of mysterious circumstances that should not have happened for which there is no explanation. Aaron, if there is anything I can do to help you please let me know. So in conclusion, I'm not done, I'm just not happy. This was supposed to be a short email, oops. Matt Speak Freely

5 7