July 2015 - tor-relays - lists.torproject.org

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