- tor-relays - lists.torproject.org

Internal server error while fetching from dizum
by Klaus Layer 09 Jan '12

09 Jan '12

Hi, my relays are getting 500 error while fetching data from authority dizum. Can someone explain what is happening with this tor authority? Regards, Klaus 14:25:51 [WARN] Received http status code 500 ("Internal Server Error") from server '194.109.206.212:80' while fetching "/tor/server/d/C539CB98343680892C46D0A70770E6D0A4A39564+E5A7994519731C2C3349AAA4C2A38CED2CE74457+E8507D31268490E9E4E8A2110E371F1537156C75+E8BCD670FFB8ADF73195BDB9362ACDDB28F704A5+E94B92087B4614CB7F1C9CC1191C383- 7D890C60E+EA71B375FC45F026C854C903887D981CF19B7326+EA9DE146A13B316D2F3D5C2ACF491C068B93FF9D+EB896E11C16C0531D83560D3CBBEF97AF2FFF4D5+ECEBAAF01CA177EEB68A8A6838E4A16- BD54749F6+ED5A60237FDCA188DF30DC380536754DFBF01404.z". I'll try again soon.

2 3

consensus update request
by Scott Bennett 08 Jan '12

08 Jan '12

The last consensus document expired about 15 hours ago. I understand that the authority operators and tor developers are probably occupied with fixing whatever is the trouble, but if someone in that group of individuals can spare a moment to fill us in on what is happening, I, for one, would greatly appreciate it. FWIW, I think a page on the torproject.org web site for very brief status updates on extraordinary situations like this one would be a good and helpful addition. Thanks much, and best of luck getting things working right again. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

Relay vs. bridge: difference in traffic?
by Steve Snyder 06 Jan '12

06 Jan '12

Can someone tell how being a bridge compares to being a regular exit node in terms of traffic? I can see how there would less traffic as a bridge since the node isn't advertised. On the other hand, there are many fewer bridges than regulat nodes so maybe the traffic on a given bridge is greater? Thanks.

2 1

not specified families
by Aurel W. 06 Jan '12

06 Jan '12

Hi, when I browse through the list of relays I find many router names, which correlate in some way, but which don't specify a family in their descriptors. Just to name a few: * 2* c5VycfOP * 3* c516a * Caldron, Caldron2, Caldron3 * BlgTOR2, BlgTOR * DwarfHappy, DwarfSleepy, DwarfSneezy, DwarfDopey * DONATIONxTORx0 - DONATIONxTORx7 and so on,... is there a reason, why there is such a high number of relays, which fail to specify a family, since this seams rather striking? aurel

2 1

relaytorkiri
by Nick Walke 03 Jan '12

03 Jan '12

I'm showing that tor is currently using 12 - 14 Mbps on my relay, however, the status page for my relay ( http://torstatus.blutmagie.de/router_detail.php?FP=192bdf2831c1b007a08dc3c1… ) does not reflect this speed. Is there a reason for this? Nick

4 7

Received botnet/drone abuse complaint
by Steve Snyder 03 Jan '12

03 Jan '12

I received a botnet/drone complaint from shadowserver.org today (delayed due to holidays) regarding my exit node: timestamp ip port type infection cc cc_port 12/29/2011 19:52 173.208.132.210 48586 32097 US MISSOURI KANSAS CITY tcp mebroot ukixxuug.com|MAOS/0EC20201 14DF137A55320641 84.163.151.128 80 3320 DE 1 If I'm reading this correctly, they identify "mebroot" as the source of the problem. As this is a Windows MBR trojan it obviously doesn't apply to my Linux system. I scanned my system anyway and found no unexpected processes running. My DirPort is set to 80, which may explain that value in the complaint. Any thoughts on what to do to avoid further complaints? Shadowserver addresses the topic of Tor exits here: http://www.shadowserver.org/wiki/pmwiki.php/Involve/TORNodesAndReporting Thanks.

2 1

planned downtime
by cmeclax-sazri 02 Jan '12

02 Jan '12

Sometime this week (I haven't decided when yet) I'll be down for a few hours to upgrade memory. cmeclax

4 3

Abuse complaints about brute forceing via ssh
by Klaus Layer 02 Jan '12

02 Jan '12

Hi, within two days I received abuse complaints from my ISP that someone used my exit node to brute force ssh accounts of two different ISP. Unfortunately I am forced to block port 22 to avoid shutdown. Anyone else who suffered from such attacks these days? Regards, Klaus

7 8

unplanned outage
by cmeclax-sazri 27 Dec '11

27 Dec '11

I have been off line since noon (17 UTC) Friday when a man with a backhoe cut the thicknet cable that connects me to the Internet. The repairmen just came and patched the cable and I am on line again. cmeclax

2 2

Bandwidth Authority PID Feedback Experiment #2 Starting
by Mike Perry 22 Dec '11

22 Dec '11

Over Thanksgiving and into early this week, we ran an experiment to test a feedback mechanism to attempt to allocate usage of the Tor network such that the measured stream capacities through all relays became equal: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuth… This experiment failed in 3 ways: 1. It drove many relays down to 0 utilization. Scott Bennett noted this in his post to tor-relays, and at least one 10Mbit relay operator also commented on the traffic drop-off of their node in #tor. 2. It only created one PID 'setpoint' for the entire network, even though different types of nodes see different load characteristics, and despite it being impossible to shift load from an Exit node to a Middle node, for example. 3. It kept allocating bandwidth to some relays (especially Middle and non-default-policy Exits) until they hit INT32_MAX in the consensus, and everything finally exploded. We then shut off the feedback by removing the consensus parameters. I've made five major changes to try to address these issues: 1. Don't perform multiple rounds of negative feedback for slow nodes. 2. We now group nodes by their flags into four categories (Guard, Middle, Exit, and Guard+Exit), and compute a different PID setpoint for each class. 2. Circuit failure now counts more. Circuit failure is our CPU overload signal, as nodes that hit CPU overload being dropping onionskins and failing extends. Instead of using the circuit success rate as a multiplier against the pid_error, we now actually compute a circ_error similar to the pid_error, and use it as the pid_error if it is more negative. We also now set FastFirstHopPK 0 to ensure that Guard nodes also get tested for circuit failure. 3. Raised the PID setpoint slightly, which should prevent us from piling quite so much weight onto fast relays. 5. Cap feedback via a consensus parameter. All of these changes are governed by consensus parameters. See: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuth… for more details. The parameters governing feedback are bwauthnsbw=1 and bwauthti. So long as one or both of these are present and non-zero in the consensus parameter list, the feedback experiment is active. We'll probably be running this next experiment for about a week (or perhaps longer if it doesn't explode and seems to improve performance on https://metrics.torproject.org/performance.html) starting tonight or tomorrow. Please keep an eye on your relays and tell us if anything unexpected happens over the next week or so. Thanks! -- Mike Perry

8 26