- tor-relays - lists.torproject.org

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

23 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 21 Dec '11

21 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 13 Dec '11

13 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 11 Dec '11

11 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 11 Dec '11

11 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

Significant relay usage drop down
by Klaus Layer 09 Dec '11

09 Dec '11

Hi, I am running two relays with the fingerprints D223399907113A1F216AAA64997BC1D4CFA8E1AC and 945CBBA599808018749DDC4EBB592168F2858C1B. For the first relay I am observing a significant usage drop down during the last 12 hours. The second runs as usual with a high throughput. I am wondering what the reason for this drop down could be. Are there any changes in the configuration of authorities? Is someone from the core TOR developers doing tests with the load distribution? Best regards, Klaus

3 3

ISP thinks a relay is under attack from other relays
by Daniel Bryg 07 Dec '11

07 Dec '11

Hi, This is mostly just an interesting anecdote but there are also a few questions. Hetzner informed us (see below) about an attack on our relay (not an exit). It looks like it's just normal traffic from other relays so all is good, but the switch sees incoming activity almost 3x higher than what comes in on the server's interface (90Mbit/s, 13k packets/s). If most of packets are dropped, it must affect the performance of Tor connections. Is this because the Tor network is overwhelmed with traffic and are all relays subject to much higher requested traffic than their limits? Thanks, Daniel. Direction IN Threshold Traffic 200 MBit/s Sum 8,828 GByte/300s (241 MBit/s), 9.436.000 packets/300s (31.453 packets/s), 317 flows/300s (1 flows/s) External 109.236.85.157, 0,444 GByte/300s (12 MBit/s), 341.000 packets/300s (1.136 packets/s), 1 flows/300s (0 flows/s) External 93.114.44.37, 0,435 GByte/300s (11 MBit/s), 321.000 packets/300s (1.070 packets/s), 1 flows/300s (0 flows/s) External 46.165.196.73, 0,373 GByte/300s (10 MBit/s), 287.000 packets/300s (956 packets/s), 1 flows/300s (0 flows/s) External 91.208.34.12, 0,260 GByte/300s (7 MBit/s), 217.000 packets/300s (723 packets/s), 1 flows/300s (0 flows/s) External 212.117.161.80, 0,256 GByte/300s (6 MBit/s), 191.000 packets/300s (636 packets/s), 1 flows/300s (0 flows/s) External 212.26.1.109, 0,241 GByte/300s (6 MBit/s), 363.000 packets/300s (1.210 packets/s), 2 flows/300s (0 flows/s) External 174.140.167.122, 0,238 GByte/300s (6 MBit/s), 177.000 packets/300s (590 packets/s), 1 flows/300s (0 flows/s) External 109.163.225.203, 0,182 GByte/300s (4 MBit/s), 142.000 packets/300s (473 packets/s), 1 flows/300s (0 flows/s) External 94.23.164.42, 0,174 GByte/300s (4 MBit/s), 137.000 packets/300s (456 packets/s), 1 flows/300s (0 flows/s) External 137.56.163.64, 0,170 GByte/300s (4 MBit/s), 157.000 packets/300s (523 packets/s), 2 flows/300s (0 flows/s) External 173.254.192.38, 0,166 GByte/300s (4 MBit/s), 143.000 packets/300s (476 packets/s), 1 flows/300s (0 flows/s) External 188.165.26.254, 0,163 GByte/300s (4 MBit/s), 134.000 packets/300s (446 packets/s), 1 flows/300s (0 flows/s) External 217.115.137.222, 0,156 GByte/300s (4 MBit/s), 123.000 packets/300s (410 packets/s), 1 flows/300s (0 flows/s) External 94.23.168.39, 0,149 GByte/300s (4 MBit/s), 133.000 packets/300s (443 packets/s), 1 flows/300s (0 flows/s) External 216.24.174.245, 0,147 GByte/300s (4 MBit/s), 106.000 packets/300s (353 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.163, 0,138 GByte/300s (3 MBit/s), 123.000 packets/300s (410 packets/s), 1 flows/300s (0 flows/s) External 85.214.75.110, 0,137 GByte/300s (3 MBit/s), 117.000 packets/300s (390 packets/s), 1 flows/300s (0 flows/s) External 204.45.133.189, 0,135 GByte/300s (3 MBit/s), 131.000 packets/300s (436 packets/s), 1 flows/300s (0 flows/s) External 94.23.174.3, 0,131 GByte/300s (3 MBit/s), 112.000 packets/300s (373 packets/s), 1 flows/300s (0 flows/s) External 85.31.186.116, 0,130 GByte/300s (3 MBit/s), 104.000 packets/300s (346 packets/s), 1 flows/300s (0 flows/s) External 178.32.52.72, 0,118 GByte/300s (3 MBit/s), 104.000 packets/300s (346 packets/s), 1 flows/300s (0 flows/s) External 46.165.196.182, 0,112 GByte/300s (3 MBit/s), 134.000 packets/300s (446 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.164, 0,106 GByte/300s (2 MBit/s), 89.000 packets/300s (296 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.162, 0,104 GByte/300s (2 MBit/s), 95.000 packets/300s (316 packets/s), 1 flows/300s (0 flows/s) External 146.185.23.179, 0,103 GByte/300s (2 MBit/s), 96.000 packets/300s (320 packets/s), 1 flows/300s (0 flows/s) External 87.98.180.247, 0,101 GByte/300s (2 MBit/s), 95.000 packets/300s (316 packets/s), 1 flows/300s (0 flows/s) External 199.48.147.35, 0,095 GByte/300s (2 MBit/s), 93.000 packets/300s (310 packets/s), 2 flows/300s (0 flows/s) External 62.220.136.253, 0,092 GByte/300s (2 MBit/s), 110.000 packets/300s (366 packets/s), 1 flows/300s (0 flows/s) External 89.248.168.118, 0,092 GByte/300s (2 MBit/s), 79.000 packets/300s (263 packets/s), 1 flows/300s (0 flows/s) External 199.48.147.45, 0,089 GByte/300s (2 MBit/s), 75.000 packets/300s (250 packets/s), 1 flows/300s (0 flows/s) External 188.120.245.249, 0,088 GByte/300s (2 MBit/s), 75.000 packets/300s (250 packets/s), 1 flows/300s (0 flows/s) External 212.95.43.222, 0,087 GByte/300s (2 MBit/s), 72.000 packets/300s (240 packets/s), 1 flows/300s (0 flows/s) External 74.109.126.29, 0,082 GByte/300s (2 MBit/s), 71.000 packets/300s (236 packets/s), 1 flows/300s (0 flows/s) External 91.121.166.158, 0,081 GByte/300s (2 MBit/s), 71.000 packets/300s (236 packets/s), 1 flows/300s (0 flows/s) External 77.247.181.165, 0,079 GByte/300s (2 MBit/s), 80.000 packets/300s (266 packets/s), 1 flows/300s (0 flows/s) External 146.185.23.180, 0,078 GByte/300s (2 MBit/s), 74.000 packets/300s (246 packets/s), 1 flows/300s (0 flows/s) External 91.121.85.130, 0,078 GByte/300s (2 MBit/s), 68.000 packets/300s (226 packets/s), 1 flows/300s (0 flows/s) External 93.182.132.100, 0,075 GByte/300s (2 MBit/s), 65.000 packets/300s (216 packets/s), 2 flows/300s (0 flows/s) External 46.73.164.123, 0,074 GByte/300s (2 MBit/s), 63.000 packets/300s (210 packets/s), 1 flows/300s (0 flows/s) External 194.204.30.253, 0,067 GByte/300s (1 MBit/s), 101.000 packets/300s (336 packets/s), 1 flows/300s (0 flows/s) External 79.172.193.89, 0,065 GByte/300s (1 MBit/s), 58.000 packets/300s (193 packets/s), 1 flows/300s (0 flows/s) External 62.116.251.71, 0,065 GByte/300s (1 MBit/s), 51.000 packets/300s (170 packets/s), 1 flows/300s (0 flows/s) External 77.245.18.28, 0,064 GByte/300s (1 MBit/s), 47.000 packets/300s (156 packets/s), 1 flows/300s (0 flows/s) External 173.254.216.69, 0,064 GByte/300s (1 MBit/s), 60.000 packets/300s (200 packets/s), 1 flows/300s (0 flows/s) External 188.72.225.172, 0,061 GByte/300s (1 MBit/s), 60.000 packets/300s (200 packets/s), 1 flows/300s (0 flows/s) External 93.115.241.2, 0,061 GByte/300s (1 MBit/s), 53.000 packets/300s (176 packets/s), 1 flows/300s (0 flows/s) External 173.254.192.36, 0,059 GByte/300s (1 MBit/s), 50.000 packets/300s (166 packets/s), 1 flows/300s (0 flows/s) External 188.165.24.70, 0,057 GByte/300s (1 MBit/s), 58.000 packets/300s (193 packets/s), 1 flows/300s (0 flows/s) External 85.223.49.156, 0,053 GByte/300s (1 MBit/s), 43.000 packets/300s (143 packets/s), 1 flows/300s (0 flows/s) External 131.130.199.36, 0,052 GByte/300s (1 MBit/s), 45.000 packets/300s (150 packets/s), 1 flows/300s (0 flows/s)

2 1

Re: [tor-relays] new (to me, at any rate) message
by Scott Bennett 05 Dec '11

05 Dec '11

On Sun, 4 Dec 2011 17:47:30 +0100 Sebastian Hahn <mail(a)sebastianhahn.net> wrote: >On Dec 4, 2011, at 12:40 PM, Scott Bennett wrote: > >> About an hour and a half ago, my node issued the following message. >> >> Dec 04 04:03:56.685 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. >> >> What does it mean? And what triggers it? Is it attempting to use a relay >> listed in the directory and consensus, but finding that that relay's status >> has changed since the consensus? > >This is a message frequently seen on relays for a while now, due to a >bug in hidden service usage in 0.2.3.x clients. See >https://trac.torproject.org/projects/tor/ticket/4171 for what we know >about it. Basically, it doesn't indicate a problem with the relay, but >rather the Tor client that uses the relay. Thus, we will soon go ahead Yes, I had gathered that much. >and stop logging this at default log levels, and also fix it on the >client side. > Urrgh... It looks like you and Robert have a good handle on it, so I won't worry about it if I see it again. Thanks much, Sebastian! 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 * **********************************************************************

1 0

new (to me, at any rate) message
by Scott Bennett 05 Dec '11

05 Dec '11

About an hour and a half ago, my node issued the following message. Dec 04 04:03:56.685 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. What does it mean? And what triggers it? Is it attempting to use a relay listed in the directory and consensus, but finding that that relay's status has changed since the consensus? 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 * **********************************************************************

3 2

Re: [tor-relays] new (to me, at any rate) message
by Scott Bennett 04 Dec '11

04 Dec '11

On Sun, 04 Dec 2011 07:02:03 -0500 Justin Aplin <japlin(a)gmail.com> wrote: >On 12/4/2011 6:40 AM, Scott Bennett wrote: >> About an hour and a half ago, my node issued the following message. >> >> Dec 04 04:03:56.685 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. >> >> What does it mean? And what triggers it? Is it attempting to use a relay >> listed in the directory and consensus, but finding that that relay's status >> has changed since the consensus? > >No idea what it means, but I got the same error at nearly the exact same >time on one of my relays. Odd. > Well, maybe that is interesting. I'm on CST, which is GMT-6hrs. Do the times still match? 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 * **********************************************************************

1 0

Re: [tor-relays] consensus "Bandwidth=" values
by Scott Bennett 02 Dec '11

02 Dec '11

On Thu, 1 Dec 2011 04:55:06 -0500 Roger Dingledine <arma(a)mit.edu> wrote: >On Wed, Nov 30, 2011 at 05:51:13PM -0600, Scott Bennett wrote: >> Something new appears to be happening in the authorities' assignments >> of "Bandwidth=" values in the consensus documents over the past few days. >> Here are some statistics from the recent consensus with the following valid >> times: >[snip] >> The top ten in the above list account for 814 relays or 32.73% of all relays >> in the consensus, yet they will get little or no traffic because of the >> assigned "Bandwidth=" values. My relay's traffic went from around 55% - 60% >> of what I had hoped to contribute down to almost nothing in the course of >> about three days, and the "Bandwidth=" value assigned to it in the consensus >> is 1. For a long time, it had typically been in the high 20s to high 30s >> with occasional excursions from slightly lower to somewhere in the 50s. >> So is this sudden, massive reassignment of loads due to a bug in the >> newest tor version(s)? Or is it an intended change by the developers? > >Mike Perry is trying out more network rebalancing ideas. See > >https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuth… >https://trac.torproject.org/projects/tor/ticket/1976 >https://trac.torproject.org/projects/tor/ticket/4425 Thanks for those. I'll probably get a chance to take a look at them later today. > >The "bandwidth authority" scripts do active bandwidth measurements, >and adjust the bandwidth weights they vote about based on how a relay >performs compared to its peers. Last week "peers" were characterized >based on the self-advertised bandwidth, that is, the bandwidth in the >relay descriptor. With the new PID design, "peers" are now a function >of the weight in the consensus. Okay, but that bring in again the old problem of flailing values reported due to the feedback. If you're going to include those reported values, then tor needs to be fixed first, so that it never reports a lesser value than it has previously reported since initialization except in "unusual" circumstances, where "unusual" might be defined as something like a current value that were less than half of the value in the last descriptor published. IOW, the value should ordinarily approach the true capacity asymptotically over successive descriptor publications. If this fix isn't made, then randomly occurring slow traffic period for a given relay will result in less traffic being sent to it in the future, which would not reflect the actual capacity of the relay. Another problem is that, as I understood from earlier links you provided, Mike's testers were measuring latency, where latency referred not to end-to-end nor to round-trip packet travel times, but rather to circuit construction times. (BTW, I'm interested in the equations/matrices used to invert the data collected for multi-hop circuits to yield values for each individual node. Is there a page on your web servers that shows them?) Circuit construction, of course, requires different resources from those required simply to pass data along already created circuits, so the latency times and the data rate capacities really are not comparable types of measurements. (What is a typical correlation coefficient between them? I would expect some positive correlation, but not necessarily close to 1.) > >In theory this feedback loop should drive even more traffic toward relays >that can handle it, and even less traffic toward relays that can't, >until we reach an equilibrium. > >In practice, it drives super-fast relays to a weight of infinity, and >all the rest to a weight of zero. > >Mike thought he'd gotten things (more) right this time, but it would >appear that has hasn't: >https://metrics.torproject.org/performance.html#torperf > >Sorry for the disturbance. I think we should probably turn the experiment >off soon. But the little dip you see in the torperf graph before the >spike makes me think there *is* a point here that is better, even if we >haven't found it yet. :) > Are you sure that little dip isn't just an artifact of the T-Day holiday weekend in the U.S.? (Cool graph, BTW.:-) Anyway, thanks much for the explanations, Roger. Glad to know that 2.3.8-alpha isn't at fault. 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 * **********************************************************************

1 0

Messages "We stalled too much while trying to write..."
by Klaus Layer 02 Dec '11

02 Dec '11

Hi, I am getting many messages of this type on a node with 0.2.3.7-alpha: [NOTICE] We stalled too much while trying to write 192 bytes to address [scrubbed]. If this happens a lot, either something is wrong with your network connection, or something is wrong with theirs. (fd 1304, type Directory, state 2, marked at main.c:962). The node is running on quad core i7 with a Gbit network interface. The network connection is working. I never saw this type of messages on my other nodes. Any advice how to get rid of these messages? Regards, Klaus

1 1

consensus "Bandwidth=" values
by Scott Bennett 01 Dec '11

01 Dec '11

Something new appears to be happening in the authorities' assignments of "Bandwidth=" values in the consensus documents over the past few days. Here are some statistics from the recent consensus with the following valid times: valid-after 2011-11-30 22:00:00 fresh-until 2011-11-30 23:00:00 valid-until 2011-12-01 01:00:00 A quick count of "Bandwidth=" values from this consensus shows that just over 20% of all relays have been assigned "Bandwidth=1". The consensus contains 2487 relays in all. The top twenty by count are as follows. Count Bandwidth= % of Total 499 1 20.06 65 2 2.61 37 3 1.48 35 5 1.40 33 7 1.32 31 6 1.24 31 14 1.24 29 4 1.16 29 12 1.16 25 15 1.00 23 11 0.92 22 9 0.88 21 20 0.84 20 8 0.80 18 17 0.72 18 10 0.72 15 32 0.60 14 53 0.56 14 24 0.56 14 18 0.56 The top ten in the above list account for 814 relays or 32.73% of all relays in the consensus, yet they will get little or no traffic because of the assigned "Bandwidth=" values. My relay's traffic went from around 55% - 60% of what I had hoped to contribute down to almost nothing in the course of about three days, and the "Bandwidth=" value assigned to it in the consensus is 1. For a long time, it had typically been in the high 20s to high 30s with occasional excursions from slightly lower to somewhere in the 50s. So is this sudden, massive reassignment of loads due to a bug in the newest tor version(s)? Or is it an intended change by the developers? 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

Tor bridge relay
by SiR GadaBout 30 Nov '11

30 Nov '11

Hi, I'm a new user of Ubuntu Linux considering setting up a bridge relay on the tor network over my home connection. If you don't mind, I'd like to set out my aims first. I have a laptop currently serving a Privoxy ad-filtering proxy for my home network. The plan is to torify my iPhone whilst retaining the ad-filtering effects of Privoxy. Once I'm comfortable this is working, i'd like to turn the server into a bridge relay. 1) Can I Torify my iPhone in this manner without a jailbreak? 2) Is my use of Privoxy counter-productive? I believe it is no longer bundled with Tor owing to privacy concerns. 3) Is it possible to make my bridge relay operate only between certain hours, so as not to aggravate my ISP? I'd be thinking of making it available for ten hours every day during local off-peak hours. I could consider making it available permanently if this pans out okay, or if the timed service isn't an option. My iPhone is a 3GS running iOS 5.0.1. The laptop is running Ubuntu Server 11.10 64-bit. It has 2GB DDR2 RAM, a 2GHz Core2Duo CPU and a Gigabit Ethernet connection. My broadband is 10Mb down, 1Mb up. Thanks in advance, B.

1 0

In which countries are relays needed, disallowed?
by Steve Snyder 26 Nov '11

26 Nov '11

I tried to set up a Tor relay in the UK today and was told that UK law prohibited anonymous Internet traffic. My tentative UK ISP told me that they must be able to provide identification of users if presented with a court order. Hmmm... The topic of country-specific conditions raises 2 questions in my mind: 1. Does the Tor Project keep a list of Tor-hostile countries? I understand that such a list over time would vary in reliability, but it would be nice to know. 2. Given the ability to set up a Tor relay in any political jurisdiction, which ones would be recommended? I'm thinking of both local political conditions and the distribution of relays from a topological perspective. I'm inclined to want a non-US relay because the highest bandwith relays locations are skewed toward the US, which biases the Tor traffic though that jurisdiction. (Today's Tor Metrics report shows 17.55% of traffic coming from the US.) Is this a reasonable approach? Thanks.

6 6

could not access my own hidden service
by cmeclax-sazri 21 Nov '11

21 Nov '11

I run Torchat and Onioncat. For at least an hour last night, my Torchat showed that I was not online, but someone else was, implying that he could see me online. I have a laptop which also has Tor, but it's just a client. I verified with Onioncat that two hidden services on the same box could not contact each other, but the laptop could contact both of them. The relay is running 0.2.2.34; the laptop is running 0.2.1.30. My Torchat now sees that I'm online, without having restarted Tor. What could cause this? cmeclax

2 1

exit atlgonyovLi
by Geoff Down 11 Nov '11

11 Nov '11

Will the owner of exit atlgonyovLi please turn off OpenDNS site blocking. -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again

2 2

Middleman/guard nodes raided in the Netherlands
by David 11 Nov '11

11 Nov '11

I just wanted to let everyone know that my two Tor nodes have been raided (+all my computer equipment and everything that could store data). I'm not sure what triggered all this unwanted attention, but I suspect that it's the local police department trying to make a score after tor getting some media attention. It doesn't look to be a very 'high-tech' operation because I got a call asking me for the root password to the tor servers that are on unencrypted disks... Let this be a warning to everyone running middlemans in the Netherlands, I found out the hard way. Nicknames of the servers where AIVD and MIVD, no clue what the public key was. But consider them compromised. Best regards, David

8 10

v3 directory
by Sebastian Urbach 08 Nov '11

08 Nov '11

Hi, Does anybody run a v3 directory relay ? I read about a long term key in the documentation. Are there any others things to consider ? I would be happy if somebody would share his config :-) Thanks -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

1 0

Re: [tor-relays] bad validity timestamps on authority certificates
by Scott Bennett 05 Nov '11

05 Nov '11

On Sat, 5 Nov 2011 02:14:43 -0400 Roger Dingledine <arma(a)mit.edu> wrote: >On Fri, Nov 04, 2011 at 06:06:41PM -0500, Scott Bennett wrote: >> Nov 04 15:51:00.273 [warn] Certificate not yet valid: is your system clock set incorrectly? >> Nov 04 15:51:00.274 [warn] (certificate lifetime runs from Nov 5 04:26:47 2011 GMT through Nov 4 04:26:47 2012 GMT. Your time is Nov 04 20:51:00 2011 GMT.) >[snip] >> My system's clock gets adjusted to the network timeservers' values once per >> hour. I've checked the logs and found that the each adjustment has been less >> than 71 ms during this time. >> So the question is why are the authorities putting out new certificates >> with valid time periods beginning six or more hours in the future? Also, when >> will the authorities be corrected? > >These aren't directory authorities. These are just random relays that >you're connecting to who have clocks more than an hour off, and an >over-active log message. Oh, okay. I had thought that only the authorities passed out "certificates", which then got stored into cached-certs. I didn't know that just any old relay could do so, too. > >See >https://trac.torproject.org/projects/tor/ticket/4370 >https://trac.torproject.org/projects/tor/ticket/4371 Thanks for the explanation, Roger. BTW, those messages seem to have stopped a few hours ago. > >This is the alpha Tor, with a shiny new (and still somewhat >sharp-around-the-edges) v3 link handshake. I'm glad this one doesn't >crash, like the last one did. :) > Yup. After seeing the notes about that bug, I just waited an extra day or two to upgrade, skipping 0.2.3.6-alpha and going straight to 0.2.3.7-alpha when it became available. :-) 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 * **********************************************************************

1 0

bad validity timestamps on authority certificates
by Scott Bennett 05 Nov '11

05 Nov '11

For the last day or so, my relay has been logging messages like these: Nov 04 15:51:00.273 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 15:51:00.274 [warn] (certificate lifetime runs from Nov 5 04:26:47 2011 GMT through Nov 4 04:26:47 2012 GMT. Your time is Nov 04 20:51:00 2011 GMT.) Nov 04 17:28:37.359 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 17:28:37.361 [warn] (certificate lifetime runs from Nov 5 06:26:47 2011 GMT through Nov 4 06:26:47 2012 GMT. Your time is Nov 04 22:28:37 2011 GMT.) Nov 04 17:56:47.782 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 17:56:47.782 [warn] (certificate lifetime runs from Nov 5 06:26:47 2011 GMT through Nov 4 06:26:47 2012 GMT. Your time is Nov 04 22:56:47 2011 GMT.) My system's clock gets adjusted to the network timeservers' values once per hour. I've checked the logs and found that the each adjustment has been less than 71 ms during this time. So the question is why are the authorities putting out new certificates with valid time periods beginning six or more hours in the future? Also, when will the authorities be corrected? 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

TOR notice.log is spammed with "Certificate not yet valid" warnings
by Klaus Layer 04 Nov '11

04 Nov '11

Hi, since 0.2.3.6-alpha the logs of my instances are full of these messages: 14:56:23 [WARN] (certificate lifetime runs from Nov 3 16:15:34 2011 GMT through Nov 2 16:15:34 2012 GMT. Your time is Nov 03 13:56:23 2011 GMT.) 14:56:23 [WARN] Certificate not yet valid: is your system clock set incorrectly? Any idea how I can get rid off these warnings? Best regards, Klaus

3 3

ARM: Client locales on connections page
by Klaus Layer 24 Oct '11

24 Oct '11

Hi, I recently found the "Client locales" function on the connection page of ARM. What exactly is the number behind the country code: ir 223334 (%13) us 188412 (%11) │ it 133819 (%8 ) │ de 121516 (%7 ) │ kr 102462 (%6 ) Thanks, Klaus

2 2

TBB on same system as relay?
by Rick Huebner 22 Oct '11

22 Oct '11

I run a relay 24/7, but sometimes also want to use Tor myself as a client. Until now, I've been using the Tor Button in my normal Firefox browser to switch in and out of Tor mode as needed, but now I see that going forward, the standalone Tor Browser Bundle is the only recommended way of using Tor as a client. How can I run the TBB on my system without interfering with my relay? When I just tried it now, the TBB brought up a second Vidalia instance which then tried to command my relay's existing Tor instance instead of spawning a second one for itself. This caused it to prompt for the relay's command interface password, but I cancelled out since I suspect that allowing the TBB to interfere with my relay's Tor process would lead to Bad Things, e.g. reconfiguring its options on the fly to a client-mode config and dropping all my users. So... how do relay operators use Tor themselves, if they can't run TBB? Or is there a way to configure them to live safely together? Or have I misinterpreted the new TBB focus, and the relay bundles will continue to support use as a client in the future as they do now? I'm using Windows 7 if that matters, but I doubt it.

4 4

Metrics portal problems?
by Rick Huebner 20 Oct '11

20 Oct '11

Is the metrics portal at https://metrics.torproject.org/ partly down, or undergoing maintenance or something? I see that some of the stats don't seem to have been updated in the last week or so. Many of the graphs are truncated, e.g. https://metrics.torproject.org/users.html?graph=direct-users&start=2011-10-…, and the per-relay stats on the https://metrics.torproject.org/networkstatus.html page all seem to stop with the 2011-10-12 13:00:00.0 consensus.

2 1