- tor-relays - lists.torproject.org

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