- tor-relays - lists.torproject.org

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

04 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 29 Nov '11

29 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 25 Nov '11

25 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 20 Nov '11

20 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 10 Nov '11

10 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