- tor-relays - lists.torproject.org

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

Status of UserspaceIOCPBuffers ??
by Gordon Morehouse 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So in the documentation: UserspaceIOCPBuffers 0|1 If IOCP is enabled (see DisableIOCP above), setting this option to 1 will tell Tor to disable kernel-space TCP buffers, in order to avoid needless copy operations and try not to run out of non-paged RAM. This feature is experimental; don’t use it yet unless you’re eager to help tracking down bugs. (Default: 0) Is this description still accurate, or is it better debugged nowadays? Would this be useful to set on machines with limited memory resources, e.g. the Raspberry Pi? Thanks much for any insight. - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSJMrDAAoJED/jpRoe7/ujZX8IALXnFOs6WEQsud4UChnjdDRC Cor6LScDdXjGBvRDodMxyrF6lX50SwIaBR+zu4I4Hw2ekit8UZdBdZafWSjQgq5W KdMW1XruYBEIN2OcWSjSoZ1K2DzuOr1O77JwBhCuRcJtqqIP5yfD2TcF6AmuxHWk 82is5XCppem1b3CVobduKIVvbC6vUu+3fau5jkwrRv0xVQGTEtSWRY9TDFP5hoxB cZN+N2yYAm0pZ9+X1fFOHteKOx9r8ENsHfSCeZfKJXbbeRmklxVnZ1k3AgU2BiET L2tVs/piMOkhOd/hGX59bRk/IyvxArmXxd5+Vq9ejLZa7nmKMuOfZYbKdGo+zlE= =b1Os -----END PGP SIGNATURE-----

2 1

Re: [tor-relays] Someone is trying to overrun the Network
by tor＠t-3.net 03 Sep '13

03 Sep '13

Here is what Top on our Tor relay is doing today: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1163 _tor 20 0 628m 286m 34m R 106.3 15.3 4693:47 tor Logs filled with: Sep 03 04:12:20.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. [5700 similar message(s) suppressed in last 60 seconds]

1 0

onionoo
by eliaz 03 Sep '13

03 Sep '13

Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up & running, & the map showing it connecting to circuits, why is onionoo reporting "running":false, ? Should I worry about this discrepancy? Thanks, eliaz

4 10

Analysis of log file
by Carsten Larsen 02 Sep '13

02 Sep '13

Hi tor-relay list, I have been running a tor node for 133 days and Im starting to receive some weird messages in the log file. One of them look like this: Received http status code 504 ("Gateway Time-out") from server '154.35.32.5:80' while fetching "/tor/server/d/9169637E422C216BECD05C6CFE3AE..... I also have another one which appear regular: [warn] {NET} Failing because we have 991 connections already. Please raise your ulimit -n. First question is: any ideas how to get ride of these messages ? Second: Would it be possible to submit a log file for further analysis, and to whom should I send it ? The node is running on ARM debian box. I can of cause provide details if it necessary. Best regards Carsten Larsen Fingerprint: E1EE4FB010F28E55B7ACA2D046AB89F3B413F2A3

3 2

Re: [tor-relays] Pony C&C
by xorox 02 Sep '13

02 Sep '13

hi, xoroxDE2 176.9.122.78 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=176.9.122.78&.pubmit=Lookup xoroxFR 5.135.167.214 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=5.135.167.214&.pubmit=Lookup xoroxLU 94.242.252.225 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=94.242.252.225&.pubmit=Lookup xoroxDE & xoroxLU2 are not listed ... :-) -- xorox5025(a)gmail.com +32/496.702.589

1 0

node list or moral discussion forum
by That Guy 02 Sep '13

02 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Other node operators, could you please try your IP address? Perhaps > this could explain the recent increase in connections? > within 2 days of setting up a node at a new IP it was added to the extortionists over at SORBS :-/ a suggestion: maybe a new tor-node-moralfag-mailinglist should be set-up as to remove this soap opera from a technical mailing list. _________________________________________________________________________ GnuPG Fingerprint: 7770 D186 A06E A329 2217 3161 63EB F269 37B8 8644 _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSJIVTAAoJEGPr8mk3uIZEJa0P/3nbn6UJyWCKPL1qi3KZ80fE T1OUYJVJKFAlN+u1Ur59CZWS2tsHJUhES4ovOj1gWF7TdrORS/knojQwM1JDyrWU 2b5Dw/jXnmf2BabliXKebk6BktEiN8I41UlVT/3MtZRnI3K1xCw0tvXy1Em3e1pJ V5EttYsylw6MXX00cO9L+LiQOHRATriTIYCUfdLmdamFkJyS27WZgEtVJ/zQGNpo dqUka2Wbns8gKPRr+4qdnA7JulM6P+gsS2hwOf+cSsTek0j9SU4UR3LLNJRXj6d/ ftCkBmp+9Bwc6FCfrT3msGDqIijei+yYjcD+ptoo9mdL/QI7GDCVbHpljowkBegS 0yvdub+WNHULjQ2bxumzi1m6DI91hAfTqwQTEUhhe8Co0/GLsjCelYdhDrTBdWIm ykH/2fqpkv2HsyK20qcUicJiijOjQODW5Ctxr7P3i9fMIi8vO/YCS7/kWwspQhXH fmdsbLzUnjpJuBU9OacuuVldOIw8Yit5URd8zLlF8Pai2a5eeedLKdG/84biKWsE 12iaJl1Ub+Wyg3FkG0/lXp1n2ANATfG3CZnAamnqwylk9N7a714LgK2jhFcRrMZE aHHIrzfEpYSceukFq8G8o6oL7zExC2i0xk8B+0pWCPkoRVw9pmXnRLvFs1HSV2f3 7b9fRFCfVB/EWq0fV9YC =d/kt -----END PGP SIGNATURE-----

4 3

Unsub me please?
by Susan Harbison 02 Sep '13

02 Sep '13

Thank you.

3 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

Re: [tor-relays] Pony C&C
by Pierre Dennert 02 Sep '13

02 Sep '13

Ich checked both of my Exit nodes: IP Address 91.219.238.107 is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet. <- uptime ~16 days IP Address 84.201.38.234 is not listed in the CBL. <-- New node, uptime < 24hrs > This was detected by observing this IP attempting to make contact to a > s_patcher Command and Control server, with contents unique to s_patcher C&C > command protocols. Not cool at all, let's see how the new node works out. > I have been running a Tor exit node for only 2 days on a fresh IP address. > However, that IP address is now blocked by spamhaus because it apparently > tried to contact the Command and Control server of the "pony" malware: > > http://cbl.abuseat.org/lookup.cgi?ip=5.79.81.200 > > Other node operators, could you please try your IP address? Perhaps this could > explain the recent increase in connections? >

1 0