tor-relays August 2013

tor-relays@lists.torproject.org

96 participants
75 discussions

Need help to get TorDNSEL compiled
by BlueStar88 26 Jun '14

26 Jun '14

Hi there, today I've read about the outage at "check.torproject.org". Since my torcheck-service "torcheck.xenobite.eu" needs the underlying TorDNSEL feature I'm trying to get this to work on my host. Like this I won't need to query the TorDNSEL-part of "check.torproject.org" anymore. I'm not into programming and do not know anything about haskell, c++ and such. So be patient with me on such matters. ;-) I've DL'ed the code from the internet website mirror [2]. I've prepp'ed all the dependencies using lucid binary packages: ghc6 6.12.1-12 libghc6-mtl-dev 1.1.0.2-10 libghc6-network-dev 2.2.1.7-1 libghc6-time-dev 1.1.2.4-2 libghc6-hunit-dev 1.2.2.1-2 libssl-dev 0.9.8k-7ubuntu8.15 libghc6-stm-prof 2.1.1.2-5 libghc6-binary-prof 0.5.0.2-1 First error I got on compile attempt was: src/TorDNSEL/Main.hs:81:21: parse error on input `#' That was quite easy thought: import GHC.Prim (Addr#) I deleted the '#' hopefully making it correct this way. Next error is some numbers too high for me now: src/TorDNSEL/DeepSeq.hs:20:7: Could not find module `Data.ByteString': It is a member of the hidden package `bytestring-0.9.1.5'. Perhaps you need to add `bytestring' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. The libghc6-bytestring-dev-0.9.1.5-125af ist installed by it's main package ghc6 6.12.1-12. Any ideas? Or are there some binary packages for TorDNSEL around, to make this more easy for me? :-P Thanks, BlueStar88 [1] https://blog.torproject.org/blog/tor-check-outage-03-and-04-july-2013 [2] https://www.torproject.org/tordnsel/dist/tordnsel-0.0.6.tar.gz

3 7

Exit relay operators: a call for packets on port 8118
by rotpoison throngnet 09 Sep '13

09 Sep '13

I am an exit relay operator in Honolulu that has posted to this list before, on the same subject. I am hoping that some other exit relay operators can sniff for packets to destination port 8118 (usually used for Privoxy) to confirm that they are seeing the same thing I am on all exit relays that I have set up in the last half year. Depending on your network configuration, you might have to instead record firewall logs for that port. Don’t worry, unless you have your Privoxy service open to the world, you won’t be intercepting or eavesdropping on any legitimate traffic. You should just be seeing SYN packets from a few hundred-strong net of Windows servers now hosted at Gorilla Servers, Ubiquity/Nobistech, and Limestone Networks, with a handful at Psychz. I am calling this malicious (?) net of Windows servers Rotpoi$on. I have more details in the most recent blog post at https://b.kentbackman.com Thanks for your help. - Kent

5 5

ExitPolicy reject *:* ships commented out?
by gordon＠thisblueroom.net 07 Sep '13

07 Sep '13

I convinced a friend to run a Tor relay (he was happy to do so) but he claims he just upgraded and that this line: ExitPolicy reject *:* # no exits allowed is commented out by default. So his VPS got shut down over a bunch of complaints and he got banned from Freenode on it. Is that true? I could've sworn 0.2.4.x shipped with that as the *default* exit policy - as it should, given the potentially catastrophic legal consequences in some countries for those setting up a relay who unwittingly set up an exit relay rather than a middle node. Best, -Gordon M.

9 9

obfsbridge operators: git master enables client statistics!
by George Kadianakis 04 Sep '13

04 Sep '13

Greetings obfsbridge operators, tl;dr, you might want to upgrade your tor to the latest git master. Trac tickets #4773 and #5040 have been merged to tor's git repository. This means that if you run the current git master, your obfsbridge will produce interesting statistics. Specifically, your bridge will count the number of its unique users like normal bridges do (but because of some complications it was not so easy for obfsbridges). It will also count the number of users per transport. Your bridge will then send these statistics to the bridge authority, and they will be published in metrics.torproject.org so that we can easily track the deployment of pluggable transports. You can experience the stats yourself by peaking at $DataDirectory/stats/bridge-stats. BTW, make sure that you are using the latest obfsproxy written in Python, and not the obsolete obfsproxy written in C. Cheers!

2 2

A bit more evidence on circuit creation storms
by Gordon Morehouse 02 Sep '13

02 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So, I started having "tubes clogged" problems this evening and realized, finally, that my Raspberry Pi powered relay had been weathering a circuit creation storm since about 18:11 my time. tl;dr main dev-related questions at bottom Aug 29 18:11:03.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. Aug 29 18:12:02.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [2692 similar message(s) suppressed in last 60 seconds] First off, I'm happy to note that the Pi is far, FAR more able to weather these storms running 0.2.4.x, even without the perfectly optimal OpenSSL (all jokes aside about that particular combination of three words)... Secondly, the number of messages escalated. Here is the worst: Aug 29 18:38:04.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [18258 similar message(s) suppressed in last 60 seconds] What on earth is causing so many circuit creation requests in such a short timespan? Again, a Pi-specific note - on 0.2.3.x, the Pi would have crashed or Tor been killed before this number ever reached five digits, so 0.2.4.x is better! I has a metric! However, note that whatever is going on starts plugging up the works in Tor itself: Aug 29 18:18:36.000 [notice] Tried for 129 seconds to get a connection to [scrubbed]:993. Giving up. (waiting for circuit) Aug 29 18:19:04.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [7190 similar message(s) suppressed in last 60 seconds] Aug 29 18:19:14.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 172 buildtimes. I assure you, my network connection speed didn't change. I still don't know how in the Tor protocol a circuit creation request is made, but maybe it was them gobbling bandwidth. Probably not, though? There was an increase in average TX/RX bandwidth during this incident, but not to levels that are in any way out of the ordinary for how I use my Internet connection. However, it's still causing trouble with my router (which is running Tomato). Check this out: Aug 29 18:56:14.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [13867 similar message(s) suppressed in last 60 seconds] Aug 29 18:56:40.000 [warn] eventdns: All nameservers have failed [snipped similar "too slow to handle" messages] Aug 29 19:05:19.000 [notice] eventdns: Nameserver 192.168.1.1:53 is back up My main question: How do circuit creation requests on one's Tor relay cause load on one's network infrastructure? Is it DNS requests? Is it TCP connection state entries? It's not bandwidth, we observed that above, and my router can handle far faster pipes than the one it's on currently. The DNS failing is a sign that the router is under severe stress. Back in the 0.2.3.x days, I often had to reboot the *router* after one of these storms, not just the Tor relay. And again - do we really know what is causing this? Something seems seriously wrong with the kind of numbers I'm seeing coming in to a node with MaxAdvertisedBandwidth 250KB. I think a bug should be opened about this, if there isn't one already. Regards, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSIAT1AAoJED/jpRoe7/ujuK4H/06MxbDHlN2uHjae6XurDib1 3yxXhHAUXC5pcP8smLQgqqtazTweeQDfIOT78QS9I0MB5z7ZnAYYsjs1/tJ1AKhb GkHtYXnlaZCxuP/oHlZYVsEhKXGGRSrXQM+y9f4uoukCn7KyVlCPF9oz2wBtSLqE qCENCZydn7nPUL6mRxveCoUvVXcGfBvm9uk17SmfuV2e6eDr5NMM4x2IxsZAYzLq hfYOUs8xLMqldsFqIaIV5J8sKwurI040P+TpZNVe7anB1ZF7uNRPfiyGrG7/JgTq aiGTyPArEdLnqYcRwGW+HbXBhQBjqF5yLt5Jj+kXXG5qBvaLQ3h/7IT7CJFr8GI= =eaXx -----END PGP SIGNATURE-----

6 9

Being flooded.........
by Allan Moon 01 Sep '13

01 Sep '13

....................by virusessince starting relay. I run several anti viral and malware routines daily and ever since deciding to start relaying, they are all being stretched to their capacity. Let me know when the sys is cleaned up. Maybe include an anti viral with the relay setup and update it thru the software. Make it so no one can connect to Tor unless they are certified clean.

12 12

Re: [tor-relays] huge increase in relay traffic
by Jeroen Massar 01 Sep '13

01 Sep '13

On 2013-08-30 20:39, Yoriz wrote: [..] > Aug 29 23:19:59.000 [warn] Received http status code 504 ("Gateway > Time-out") from server '154.x.x.x:80' while fetching > "/tor/server/d/54BDF368367470FCBF015...067.z". I'll try again soon. > Aug 30 00:14:52.000 [warn] http status 504 ("Gateway Time-out") reason > unexpected while uploading descriptor to server '154.x.x.x:80'). That likely is the following ticket: https://trac.torproject.org/projects/tor/ticket/8458 Greets, Jeroen

3 4

Node specialization
by Pascal 01 Sep '13

01 Sep '13

http://torstatus.blutmagie.de indicates that only 21.4% of Tor nodes are exit nodes. Are we wasting this precious resource by running non-exit traffic through these nodes? -Pascal

5 4

Re: [tor-relays] new relays
by tor＠t-3.net 31 Aug '13

31 Aug '13

This thread did go goofy and bad (and off-topic, given the subject in the emails). It seems clear that there are important reasons Tor could never begin examining/taking direct responsibility for/filtering the content that flows through it (as opposed with disallowing specific ports, which is different). Asking for this seems naive. On Saturday 31/08/2013 at 8:54 am, Steve Snyder wrote: > > > On 08/30/2013 08:05 PM, Andrea Shepard wrote: > [snip] >> >> If I were going to work on filtering by technical means, it'd be >> filters to >> keep neo-Puritans like you out of my life, thanks. > > Well said. This whole thread is example 87653478965432 of the > "censorship is A-OK if I don't like it" mindset. > > Maybe we need a competitor to Tor, a privacy network that only allows > pictures of cute kittens and puppies as traffic. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Overload data for Exit vs Non-Exit (and Guard vs Middle)?
by Mike Perry 31 Aug '13

31 Aug '13

To try to get to the bottom of the recent influx of clients to the Tor network, it might be useful to compare load characteristics since 8/19 for nodes with different types of flags. People with Munin setups: it would be especially useful if you could post links/graph images for connection counts, bandwidth, and CPU load since 8/19. I'm particularly interested if people with just the Exit flag (w/o Guard) are seeing increased connection counts that aren't explained by uptime or ramp-up. So far the only datapoint I have for this is https://www.torservers.net/munin/torservers.net/psilotorlu.torservers.net/i… but it looks like that node just rebooted and possibly rekeyed, so it's connection increase could just be due to that. It would also be interesting to see if Guard+Exits are seeing a greater increase in connection counts than just Guards. I'm also wondering if any aspects of the load has any other relation to node flags. -- Mike Perry

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays August 2013