tor-relays December 2011

tor-relays@lists.torproject.org

23 participants
18 discussions

torrc "permission denied" warning
by tony 26 Jan '12

26 Jan '12

In the Tor logs for a relay, I get the following message: Dec 19 19:42:23.662 [notice] Renaming old configuration file to "/etc/tor/torrc.orig.1" Dec 19 19:42:23.662 [warn] Couldn't rename configuration file "/etc/tor/torrc" to "/etc/tor/torrc.orig.1": Permission denied I've played around with file permissions but it doesn't help. Tor seems to be working. Does the error matter? Running Tor on a Ubuntu Server 10.04 LTS Feedback much appreciated.

3 2

Tor Deprecation Notice
by Damian Johnson 20 Jan '12

20 Jan '12

Hi all. As per ticket 4788 [1] we'll soon be removing relays that are out of date and no longer safe to run, which includes anything older than version 0.2.1.30. When I last checked this included 257 relays [2] and I've already notified the 107 of those that had contact information available. If you're running one of those relays then you'll need to upgrade to keep operating. Sorry about the inconvenience and thanks for running a relay! -Damian [1] https://trac.torproject.org/projects/tor/ticket/4788 [2] https://trac.torproject.org/projects/tor/attachment/ticket/4788/old_relays.…

3 2

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

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

arm client locale stats on connection page
by Klaus Layer 20 Dec '11

20 Dec '11

Hi, I am using arm to monitor 3 tor nodes running on the same box. On the connection page I get very different results when pressing "c" to get the client locale stats: Node A - nothing happens Node B - the window with the client locale stats is displayed Node C - a message "Usage stats aren't available yet, press any key..." is displayed Under which conditions are the stats available? Regards, Klaus

2 2

bandwidth authority test
by Softail 12 Dec '11

12 Dec '11

I'm also running a guard relay that for some months was pushing 600kBs pretty steadily. In the last couple weeks it's lower and very variable and today it has basically cratered. Is this a likely results of the bandwidth algorithm testing that's going on or might I have other problems? Thanks, Wayne -- A man in chains knows he should have acted sooner... Julian Assange

1 0

ARM crashes on connection tor
by Klaus Layer 10 Dec '11

10 Dec '11

Hi, I am no longer able to connect with ARM to one of my relays. ARM crashes with the following error: debian-tor@host:/home/user$ arm -i 127.0.0.1:4711 Traceback (most recent call last): File "/usr/share/arm/TorCtl/TorCtl.py", line 710, in _loop isEvent, reply = self._read_reply() File "/usr/share/arm/TorCtl/TorCtl.py", line 885, in _read_reply raise ProtocolError("Badly formatted reply line: unknown type %r"%tp) ProtocolError: Badly formatted reply line: unknown type 'P' Terminated To another instance running on the same machine ARM connects without any problem. Has anyone experienced the same issue or knows how to fix it? Thanks, Klaus

3 3

Logs full of "eventdns: All nameservers have failed"
by Klaus Layer 10 Dec '11

10 Dec '11

Hi, my logs are full of these messages: 05:54:07 [NOTICE] eventdns: Nameserver 127.0.0.1 is back up 05:54:07 [WARN] eventdns: All nameservers have failed At first I thought that the DNS of my ISP sucks, so I changed to Google Public DNS. But the warnings are still there. Google shows some older reports of this warning, where is was supposed to be an error in tor. Are there any news on this? I am wondering if the high bandwidth nodes from torservers and noisebridge also show this kind of messages and how they configured their nodes to get rid of it. For my node they come up every couple of minutes. Between fail and recover is always less than a second. Best regards, Klaus

5 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays December 2011