[tor-relays] FW: What's a "useful" mailing list contributor? (was Re: What's a "useful" relay?)

[Rana]

Wow. I offer to maintain a FAQ for small relays and in return I get this. 
Unsubscribed.
 
 On 3 Jan 2017, at 17:57, Rana <ranaventu...@gmail.com 
<mailto:ranaventu...@gmail.com> > wrote:
 
 @teor
 I hereby volunteer to maintain a FAQ for operators of small relays (or noob 
operators). Which means I would be watching this list, generating the Q and 
from time to time alerting this list to the appearance of new questions and 
answers, to allow knowledgeable people to do quality control. And/or inviting 
people to convert their answers on this list  to the FAQ answers. This would 
relieve them from answering the same question over and over again and reduce 
the influx of questions from noobs (like myself J). I believe this would also 
strengthen the community and reduce the frustration of small relay operators  
and – who knows? – even lead to advancements in Tor design to make better use 
of them.

I would appreciate that, but please learn some mailing list etiquette
first. Otherwise, your contributions may be ignored by many people on
the list.

Some examples:
* make sure each email adds something valuable to the conversation
* structure your emails well:
  * learn how to bottom-post, even if your email client doesn't support
it
  * learn how to quote others' emails to provide context to your
response
* try to write succinctly
* keep the volume of your emails down:
  * write one response to a thread each day
  * search for similar threads before starting a new one
  * wait until an active thread is finished before starting a new one
 Caveat: I need someone (Tor project people) to create the Wiki on the site and 
let me admin it.

Demonstrate you can do the things above, and I'll gladly set this up
for you.


T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

  _  





___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

>Any people who will use your relay on a circuit will also damn you to run such 
>small relay. This is so slow and not usable for day to day web surfing, 
>specially if you are well connected to Internet (fiber or decent ADSL).
>Personnally, I have around this speed directly for my ADSL Internet connection 
>(500/80kB), and I rant each day I have to upload something…

The question remains whether  NOT having access to my relay makes life easier 
for people. Sometimes I guess you are right. But when all the big relays get 
overloaded, small relays could provide MORE bandwidth than large relays.Both 
your and my statements are qualitative, I would like someone who knows the 
numbers to respond.

>Memory and TCP ports ?
>A node need to maintain thousands of circuits. This consumes a lot of memory 
>(400MB on one of my guard) and a lot of TCP sockets (14k sockets).

There are 850 MB unused memory on my $35 Pi relay that is used to 7% of its 
link capacity. Therefore the memory limitation you cited is irrelevant.

>Those parameters don’t scale very well if you have more nodes (65k TCP port 
>only, or some hundred of GB of RAM). 

HUNDRED GB of RAM? I believe you mean hundred MB? In this case ditto.

>Currently, with standard hardware, seems we can’t host more than 10 or 20× 
>more nodes than today without hitting some hardware limit.

10x more nodes than today sounds good to me. My understanding is that Tor is 
nowhere near breaking out of its 7K and moving to this limit.  Therefore, the 
spare capacity of small relays could be used.

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Speed up of reconnections after IP Address change

[Rana]

Such script is one typical entry that I would put on the small relay operator 
Wiki (see my earlier post)

Rana

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Dr Gerard Bulger
Sent: Tuesday, January 03, 2017 10:49 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Speed up of reconnections after IP Address change

I would be interested in such a script to SIGHUP each time IP changes if anyone 
makes one!



-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: 03 January 2017 07:32
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Speed up of reconnections after IP Address change


> On 22 Dec 2016, at 18:19, balbea16 <balbe...@gmx.de> wrote:
> 
> Hi There,
> I only have a dynamic IP address and my ISP changes it almost every 
> time
after 24 hours. It is somehow sad to see 1.400 connections drop to almost none. 
After the change it takes 20 minutes until my OR notices this (our IP Address 
has changed from ...). It than takes another hour until the connections start 
to actualy rebuild. This means it takes more than an hour (every per day) to 
reach the normal operating Mode.
> 
> Is there any way to speed up this process? Could adjust the torrc 
> script
for instance?

No, sorry, new relay details are only published in the tor consensus every hour.

To reduce the 20 minute delay, you could write a script that issues a SIGHUP
(reconfigure) to tor when your address changes.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org





___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What's a "useful" relay?

[Rana]

@teor
I hereby volunteer to maintain a FAQ for operators of small relays (or noob
operators). Which means I would be watching this list, generating the Q
and from time to time alerting this list to the appearance of new questions
and answers, to allow knowledgeable people to do quality control. And/or
inviting people to convert their answers on this list  to the FAQ answers.
This would relieve them from answering the same question over and over again
and reduce the influx of questions from noobs (like myself :)). I believe
this would also strengthen the community and reduce the frustration of small
relay operators  and - who knows? - even lead to advancements in Tor design
to make better use of them.
 
Caveat: I need someone (Tor project people) to create the Wiki on the site
and let me admin it. There is already a severely underused wiki with a
couple of answers that someone once referred me to, with a disastrously
difficult captcha that I could not pass (why have captcha on a Wiki in the
first place is beyond me)
 
 
-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of teor
Sent: Tuesday, January 03, 2017 8:26 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] What's a "useful" relay?
 
 
> On 24 Dec 2016, at 18:56, Rana < <mailto:ranaventu...@gmail.com>
ranaventu...@gmail.com> wrote:
> 
> ...
> 
> What is needed is a standardized feedback on WHY the relay has such a low
rating. This could cause at least part of the operators to take care of the
bottleneck (eg moving the relay to another location, or abandoning the home
relay and replacing it with a hosted one). And if the home relay is indeed
as harmful as some people here think, the recommendation should be issued to
shut it down, instead of leaving it hanging there doing nothing or even
harming Tor. Such feedback could significantly improve the quality and
effectiveness of Tor.
> 
> Based on the discussion here, the people who run Dirauths and bwauths know
very well (or at least can easily find out) the reasons for relays getting
low rating - why not automate the  communication of the reasons to relay
operators in clear, unequivocal and actionable terms?
 
You could try compiling a FAQ from the answers you and others have received.
 
Or, someone could volunteer to create a relay performance analysis tool. But
it might not be as simple as you think. There are many variables, and it's
hard to work out what's actually happening to a relay without access to the
relay itself.
 
> I get the feeling that people are trying to be "politically correct" here
and it's a pity (although they DO respond fully and frankly when asked a
direct question).
 
Perhaps some of us struggle to answer similar questions in the same level of
detail all the time. I know I do. It takes a lot of time to elicit the level
of detail needed to provide good answers.
 
Also when we're not polite, the discussion escalates into long threads with
few interesting posts. So most of us learn to avoid that.
 
T
 
--
Tim Wilson-Brown (teor)
 
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

 
 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

@teor
>I think you are talking about a different network, which is not Tor as
currently designed, implemented, and deployed.
>In particular, how do you get decent throughput, reliability, and low-
latency out of tens of thousands of devices?
>This is an open research problem, which the Tor design does not solve.

Sorry for being thick-headed but 

1. I do not see the connection between the latency and the number of relays.
However many relays there are in the pool, there always will be  3 relays
(or so)  per circuit.

2. I also do not see the problem with throughput and latency. If the relay
is small, it should be used in accordance with its capacity, which is
reported in consensus. Many small relays should increase the probability of
finding one that has spare bandwidth (my residential relay is, for example,
idle 93% of the time despite having decent ultra-stable 153 KB/s bandwidth
and static IP);

3. I do not see the problem of reliability. Reliability is easily measured
and reported. The same relay is VERY reliable - totally stable for weeks,
yet still under-used only because it is small.

4. I do not see why the current design of Tor prevents using more relays. I
do not believe the current design is limited by design in the number of
relays it can support.

I am sure that I am missing some deeper insights. What am I missing?


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

To recap, we are talking about
https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C
C6

Thanks but your explanation does not seem to apply here. The measured BW is
equal to the limit and has been the same rock solid number (153.6 KB/s) for
weeks. As you see on the graph, the actual throughput is nowhere near the
limit. The IP is static and therefore never changed. The relay almost never
restarted and certainly did not restart for weeks before the drop occurred
(uptime is 24 days now). And as you see it never really recovered from the
drop and seems to have stabilized at about 7% of its (as measured and
reported in Atlas) capacity. 

What am I missing?


-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of teor
Sent: Tuesday, January 03, 2017 5:31 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic
IP


> On 28 Dec 2016, at 02:50, Rana <ranaventu...@gmail.com> wrote:
> 
> Speaking of guards, could someone come with a theory pf what happened
here? The IP is static, the relay exists for 18 days and has Stable flag
since maybe 2 weeks, the measured bandwidth -153 KB/s - exactly equals the
bandwidth limit in torrc for 2 weeks now. What could explan the sudden
catastrophic drop in bandwidth after linear if not exponential growth? This
articledescribes exactly this pattern but the drop occurs when a Guard flag
is awarded. In this case, no guard fag. Any ideas?

When your relay reaches its bandwidth rate, it has no spare capacity.
Therefore, the bandwidth authority measurements (and consensus
weight) are lower.

Since the consensus weight is lower, clients use the relay less.
The relay has spare capacity, and the bandwidth authority measurements (and
consensus weight) are higher.

This feedback process continues until the relay utilisation and consensus
weight stabilise.

(Large page)
https://consensus-health.torproject.org/consensus-health-2017-01-03-02-00.ht
ml#707A9A3358E0D8653089AF32A097570A96400CC6

In this particular case, the changes are large.
This might be because:
* the bandwidth rate is low,
* the connection speed is high compared to the bandwidth rate,
* the IP address changes, or
* the relay restarts, or
* perhaps some other reason.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org





___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

Known to whom? Is there a Tor police that researches "unknown" guards? How do 
you measure "known"? How do they become "known"? Something akin to key signing 
parties? Secret meetings in Munich biergartens?

Conversely, if someone installs a high performance relay, during the first 70 
days is there a secret police investigation giving the operator a clean bill of 
health or conversely marking her as a rogue?

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Zwiebel
Sent: Monday, January 02, 2017 4:19 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] How can we trust the guards?

> Currently, most of the major guard operators are well known people
are you sure?

- Zwiebel, 33rd on that list
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

Sorry

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Aeris
Sent: Monday, January 02, 2017 3:56 PM

>Currently, most of the major guard operators are well known people and no 
>doubt they’re not engaged with three-letter agencies.
>https://github.com/ornetstats/stats/blob/master/o/main_guard_operators.txt

I do not know how to interpret this table. How many guards are there at any 
given time?


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Grizzly Steppe

[Rana]

My bet is that the recorded IP address dates back to the days when your node
was an exit. Naturally the Russian hackers have used Tor, probably in tandem
with a VPN - it would have been stupid of them not to, and stupid they are
not. 
 
And you are right - now the US government will blame Tor exit operators for
the sheer stupidity of email operators in political shops such as DNC that
do not force their users to encrypt email end to end. PGP is too much
trouble for them.
 
If I am right there is nothing you can do now, you have already closed the
exit. If they pressure you, migrate your relay to another IP.
 
Rana
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of Dr Gerard Bulger
Sent: Monday, January 02, 2017 10:15 AM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Grizzly Steppe
 
I ran an exit node, but gave up after too many abuse reports that annoyed my
ISP.  So I turned al exit ports off, and reports stopped as a rely.After
months and many terabytes of data I get an abuse complaint that my tor IP
has been used for espionage. 
 
"NCSC have been made aware of a report and associated malicious indicators
released by the United States Government relating to malicious cyber
activity. A copy if the report and indicators can be found at the following
link:-
https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicio
us-Cyber-Activity
Details within this report indicate network assets which may have been
compromised or associated with malicious activity. We have identified the
following IP address from this report as x.x.x.x   As a minimum, it is
recommended that you check systems and any available logs concerned with the
above addresses for indications of malicious activity"

There are no other details as to HOW my tor relay is being used.  The
espionage seems to relay on the stupidity of recipients on receiving emails
asking for passwords.  I am not sure HOW ISP or relay service can stop that.
Or is it that my relay was being used to transfer the data?
 
I assume my IP was found by way of a DNS leak which I need to look into.
There is nothing else I can do as a relay to stop this or is there?
 
Gerry
 
 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

@Mirimir
>> This is not Blockchain where hundreds of thousands of greedy selfish 
>> genes are working together for non-collusion.  A practically zero- 
>> effort collusion of already fully cooperating FIVE EYE agencies (US, 
>> UK, Canada, Australia, New Zealand) is needed to sprinkle several tens 
>> of rogue relays every month all over the globe, hosted at unsuspected 
>> hosters, looking perfectly bona fide. All they need is maintain some 
>> bandwidth and stability (why not?) and wait 70 days and - hop! - they 
>> are guards.

>That seems plausible. I don't know how the community of relay operators works. 
>But I suspect that, if you're right, many known and trusted relay operators 
>must be covert operatives. While that's not impossible, it would represent a 
>huge investment.

I've been through this already, and made a calculation of the completely 
negligible - in government terms - amount required to pay for hosting 4000 
powerful nodes that are indiscernible from honest relays and are scattered all 
over the world. A huge investment is emphatically NOT required for this. As to 
operatives, I see no reason why a single employee could not control 500 rogue 
relays from a single $1000 PC.  Say, spending her day revisiting 25 relays 
daily, doing maintenance. That's assuming zero automation. With some automation 
software (say, flagging relays that need attention, most of them don't most of 
the time), a single employee could control the entire 7000. Where's  the "huge 
investment"?

Tor model breaks down when facing a modest government adversary for the simple 
reason that having only 7000 relays total, with a minority of them carrying 
most of the traffic, invites cheap infiltration and takeover by state 
adversaries.

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

@Sebastian
>> On 02 Jan 2017, at 07:28, Rana <ranaventu...@gmail.com> wrote:
>> I think I already covered the "if it exists" part. Sticking to the original 
>> (old) design doc of Tor is not a practically useful strategy. I believe that 
>> Tor has MOSTLY such strong adversaries, the others do not matter much. You 
>> do not really use Tor to protect yourself from petty hackers, do you?

>I think the vast majority of Tor users are doing exactly that.

Then I can't accuse you of being inconsistent or illogical. I think, however, 
that you are very wrong. Petty hackers are not even remotely interested in 
destroying your anonymity. They are interested in your money. As long as they 
can have that, you can remain perfectly anonymous as far as they are concerned.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

@Andreas
>It will not go quite unnoticed when the set of major relays changes 
>substantially over a few months.

Tor exists for what, 10 years? 30 new rogue relays per month (monthly quantity 
designed to be proportional to the recent months growth statistic) would go 
totally unnoticed and would get the attacker to the control of 4000 relays 
today. NSA certainly has the long term planning capacity to do exactly this, 
and the required resources are negligible.

@Mirimir, @Andreas
> >This assumes that there is only one entity wanting to do that.
> >When there are multiple the game isn't that easy.

>Yes, that is a great Tor feature! Dueling adversaries strengthen Tor against 
>each other.

That's wishful thinking at best. Assuming that there are enough non-colluding 
adversaries attacking Tor and destroying each other's efforts is futile. This 
is not Blockchain where hundreds of thousands of greedy selfish genes are 
working together for non-collusion.  A practically zero-effort collusion of 
already fully cooperating FIVE EYE agencies (US, UK, Canada, Australia, New 
Zealand) is needed to sprinkle several tens of rogue relays every month all 
over the globe, hosted at unsuspected hosters, looking perfectly bona fide. All 
they need is maintain some bandwidth and stability (why not?) and wait 70 days 
and - hop! - they are guards. Sprinkling middle relays is even easier. I am not 
even talking about the broader 14-EYE intelligence cooperation that includes 14 
countries 
(https://en.wikipedia.org/wiki/UKUSA_Agreement#9_Eyes.2C_14_Eyes.2C_and_other_.22third_parties.22)

That US agencies are actively working to destroy anonymity of (hopefully only 
selected, but who knows?) Tor users is an undisputable fact. Your implicit 
assumption that Russia is also attacking Tor is, however, unfounded. I 
mentioned that they have the resources to do so. Russia has arguably MORE 
resources that the US because instead of paying for hacking services and 
infrastructure all they need to do is  threaten to put the ringleaders of their 
internationally renowned criminal hacking gangs in jail. There is, however, 
ZERO evidence that they are going head to head with America doing that. They 
seem to be much more interested in attacking weakly protected email servers of 
DNC. 

@Aeris
>Having  is not enough. You can’t just send  in hardware and expect to 
>be guard. You need to prove your worth to the network to have guard flag.
>And you also need intelligence, because your node must be VERY differents each 
>others or only few of your guard will be used (same /16 network, same country, 
>same operator => never 2 nodes on a circuit or guard set).

Ditto

>Controlling all guards is NOT a serious problem ’til you also control other 
>nodes (middle or exit).

Yep. Modify my previous posts and replace "guards" by "Guards and exits". Here 
you go.

>If you think such attacker exists, just don’t use Tor, this is EXACTLY the 
>threat model Tor can’t avoid and expressed on the paper.

I think I already covered the "if it exists" part. Sticking to the original 
(old) design doc of Tor is not a practically useful strategy. I believe that 
Tor has MOSTLY such strong adversaries, the others do not matter much. You do 
not really use Tor to protect yourself from petty hackers, do you?

I believe that what is needed is changing Tor to accommodate a lot of small 
relays running by a very large number of volunteers, and to push real traffic 
through them. The current consolidation most of the Tor traffic in a small 
number of stable, high bandwidth relays was NOT anticipated by the Tor design 
paper and makes contamination of the majority of the network by rogue relays a 
very easy job indeed.

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

@Aeris

I do not see how Sybil attacks relate to my question. The adversary will simply 
set up new nodes, without messing with attacking identities of existing ones.

As to the rest of it, let us calculate. Assuming that the adversary wants to 
control 4000 nodes for 3 years, the 70d startup period is irrelevant and 
negligible. Assuming further that operating the relays will cost the adversary 
$20/month each, the total "investment" required would be 20x12x3x4000=less than 
$3million

That’s  $1million a year to control most of the Tor nodes., You call this 
"costly"? This amount is a joke, a trifle, petty cash for any US or Russian 
government agency. FIFTY times this amount is STILL petty cash, so in case you 
think $20/month is not enough to run a relay, make it $1000 a month.

So I repeat - how is this prevented?


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] How can we trust the guards?

[Rana]

Sorry for the naïve question, but we have a total of about 7000 relays, many
of them residential and thus practically unused or very lightly used. So the
actual number of relays that carry most of the traffic is rather small, and
many of them are middle relays, leaving an even smaller number of guard
relays. This means that an adversary with a rather modest budget can easily
take over half the guards.
 
Whats’ the trust mechanism (if any) to ensure that the majority of guards
are not hijacked by adversaries?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] "Graceful" Restart of Tor-Relay ?

[Rana]

@Sebastian
>Tor has this functionality built-in, the timeout is configurable (30 seconds 
>by default). Setting too long a timeout is bad if you're a guard, because the 
>longer you wait to restart the more ?>clients will rotate away from you while 
>you're down - just restarting without any timeout at all is rude for anyone 
>currently having an active circuit, of course.

>In short: The default is a sensible compromise, if you run a no-guard relay 
>you can increase the timeout massively to be "nicer" to people with 
>long-running connections, if you're a guard you probably shouldn't.

Can you provide explicit sequence of events/commands I need to execute for such 
graceful shutdown? Eg I need to reset my router - should I stop the tor service 
from Linux command line, , then check in tor log if it has finished its 
graceful shutdown, then reset router, then start tor again? Ir is there no need 
to even check the log?



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

Speaking of guards, could someone come with a theory pf what happened here 

 ? The IP is static, the relay exists for 18 days and has Stable flag since 
maybe 2 weeks, the measured bandwidth -153 KB/s - exactly equals the bandwidth 
limit in torrc for 2 weeks now. What could explan the sudden catastrophic drop 
in bandwidth after linear if not exponential growth? This article 
  describes exactly 
this pattern but the drop occurs when a Guard flag is awarded. In this case, no 
guard fag. Any ideas?
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
balbea16
Sent: Tuesday, December 27, 2016 5:05 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
 
Hi There 
I evaluated some relays with newly assigned (red) guard flags. All of them had 
already the stable flag assigned. And (so far I could see) all of them had 
(almost) static IP addresses. In my case, this may be the reason why I don't 
get a guard flag. My ISP changes it every 24 hours. However, I'd be fine with 
"just" operating a fast middle node. 
I will keep an eye on this. 
Mike
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Minimum requirements for becoming a guard

[Rana]

What are the absolute minimum requirements for becoming a guard? 
 
[I am not asking about being trustworthy which I am obviously not, only
about bandwidth etc. :)]
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] FW: What's a "useful" relay?

[Rana]

@balbea16
 
Correction: your relay has 1400 connections, mine has 1300. Therefore my relay 
has less than 1% of the weight of your relay while having ALMOST THE SAME 
number of connections. Go figure…
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Rana
Sent: Saturday, December 24, 2016 10:12 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] What's a "useful" relay?
 
@balbea16
 
>I am actually a little bit confused now. I am one of (as Rana knows) those Pi 
>3 based OR operators with daily changing IP address. My consensus weight is 
>about 5,000, with a max. of 1,400 connections.  I would like to recomment, 
>that the TOR org should publish minimum requirements to run a relay. And, if 
>my kind of relays would bring disadvantage to the network, I would shut it 
>off. So far, I think, that small and large relays in combination are good for 
>anonymity. 
 
I am even more confused than you. My 1300 connections relay has a consensus 
weight 
<https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400CC6>
  of 38 (thirty eight). That’s less than 1% of your weight, despite having 26% 
the number of connections you have. Besides, I could never understand why 
people measure the “size” of the relay by the number of connections. My guess 
is you can have a large number of dead connections.
 
This is just another example of the lack of clear metrics and feedback to relay 
operators on the quality of their relay, including how well the relay is doing 
in terms of its usefulness to Tor, and especially of (direct or easily derived) 
actionable recommendations on how to improve its quality, including abandonment 
if it is harmful to Tor in its current form.
 
Rana
 
PS I guess this may not be that simple as possibly some relays are getting 
bashed because they are suspected of being rogue. Still, a mechanism of quality 
feedback is needed for the (hopefully the majority) of the relays that are run 
by bona fide volunteers.
 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What's a "useful" relay?

[Rana]

@balbea16
 
>I am actually a little bit confused now. I am one of (as Rana knows) those Pi 
>3 based OR operators with daily changing IP address. My consensus weight is 
>about 5,000, with a max. of 1,400 connections.  I would like to recomment, 
>that the TOR org should publish minimum requirements to run a relay. And, if 
>my kind of relays would bring disadvantage to the network, I would shut it 
>off. So far, I think, that small and large relays in combination are good for 
>anonymity. 
 
I am even more confused than you. My 1300 connections relay has a consensus 
weight 
<https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400CC6>
  of 38 (thirty eight). That’s less than 1% of your weight, despite having 26% 
the number of connections you have. Besides, I could never understand why 
people measure the “size” of the relay by the number of connections. My guess 
is you can have a large number of dead connections.
 
This is just another example of the lack of clear metrics and feedback to relay 
operators on the quality of their relay, including how well the relay is doing 
in terms of its usefulness to Tor, and especially of (direct or easily derived) 
actionable recommendations on how to improve its quality, including abandonment 
if it is harmful to Tor in its current form.
 
Rana
 
PS I guess this may not be that simple as possibly some relays are getting 
bashed because they are suspected of being rogue. Still, a mechanism of quality 
feedback is needed for the (hopefully the majority) of the relays that are run 
by bona fide volunteers.
 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What's a "useful" relay?

[Rana]

@Ivan
 
>Some best practices definitely would be awesome to have about running on 
>common (embedded) hardware. Clear notification like "your Commodore 64 is to 
>slow to be a good relay" would also be useful.
 
I agree about the need for guidelines but I disagree about the content of the 
guidelines that are needed. The data I see so far, including your report of a 
Pi with 7000 connections, is a clear indication that minimal hardware 
capabilities  are NOT the guidelines that are needed (unless a relay with 7000 
connections is still considered "harmful" or "useless").
 
My own Pi-based relay 
https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400CC6  
has just reached 1300 connections; CPU utilization: practically zero; memory 
utilization: 14.5%. The increase from 500 to 1300 connections required memory 
utilization increase of just 2%, from 12.5% to 14.5%. Clearly, hardware of the 
$35 Pi has absolutely nothing to do with residential relays being useful or 
not, save the (recently reported here) anomaly of an operator who has symmetric 
BW of 160 mbps to the home. 
 
So guidelines on hardware are evidently not needed for "normal" residential ISP 
bandwidth: it has been amply demonstrated that even a dirt cheap Pi is not the 
bottleneck, no need to spend further effort on this until the REAL bottleneck 
is resolved: the network.
 
To continue the story, the above relay of mine with 1300 connections has 
consensus BW rating of 38 (thirty eight). Why? Who knows. I get zero feedback 
on the reason for this.
 
To further continue the story, my 2nd relay 
https://atlas.torproject.org/#details/31B8C4C4F1C78F923BD906769297B15A428C4A04 
that currently has about the same Atlas-measured BW as the first relay (132 vs 
153 KB/s) and is based on exactly the same hardware and software, is clinically 
dead with almost no connections and BW rating of 13. Why?  Who knows.
 
What is needed is a standardized feedback on WHY the relay has such a low 
rating. This could cause at least part of the operators to take care of the 
bottleneck (eg moving the relay to another location, or abandoning the home 
relay and replacing it with a hosted one). And if the home relay is indeed as 
harmful as some people here think, the recommendation should be issued to shut 
it down, instead of leaving it hanging there doing nothing or even harming Tor. 
Such feedback could significantly improve the quality and effectiveness of Tor. 
 
Based on the discussion here, the people who run Dirauths and bwauths know very 
well (or at least can easily find out) the reasons for relays getting low 
rating - why not automate the  communication of the reasons to relay operators 
in clear, unequivocal and actionable terms? I get the feeling that people are 
trying to be "politically correct" here and it's a pity (although they DO 
respond fully and frankly when asked a direct question).
 
Rana
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [tor-r@elays] What's a "useful" relay?

[Rana]

@Ivan
 
>If you think that your relay is underrated or has poor performance try to 
>adjust your hardware/settings. Anyway almost every relay operator has this 
>kind of "operator anxiety". Don't worry. ;)
 
It is not about anxiety. The last thing that would cause anxiety for me is the 
possibility to find another cool project for my Pi :)
 
>If there were only blazing fast relays it would decrease anonymity because 
>these relays would be placed in some datacenters and operated by small amount 
>of people (entities).
>Tor network needs all kinds of relays to be strong. Diversity is about 
>platform, location, connectivity, etc, etc.
 
While I hold the same opinion as you (intuitively) I am interested not in 
intuition but in in a sober technical analysis, and  not in words of 
encouragement, or in the customary "thank you thank you thank you for running a 
relay"
 
I hear opinions here that small relays are not really useful, and about small 
bridges I heard here that they are actually causing DAMAGE. 
 
Those opinions were backed by technical arguments, here are a few:
 
-  the numerous small relays that change their IP addresses burden the network 
unnecessarily with frequent re-publishing of their descriptors
-  small relays that carry a small number of circuits actually DESTROY 
anonymity since the small number of circuits going through them makes it easier 
to de-anonymize traffic;
-  anonymity is much better served by a few large relays since they carry a lot 
of circuits simultaneously, and for this reason DirAuths try to saturate them 
before they direct traffic to small relays
-  the connections through small relays are quickly saturated, making using the 
internet a horribly slow and unpleasant experience
- Isis, the bridge db and bridge authority operator, has asked Tor people who 
make decisions  NOT to recommend that people run bridges on their small 
residential connections, because the need to re-distribute information about 
changed IP addresses is a major hurdle towards bridge adoption
 
Or as one DirAuth operator summarized it: "On balance, the very small relays do 
not contribute enough resources compared to the associated costs to be 
worthwhile."
 
All of which is exactly the opposite of what you are saying and what was also 
my intuitive opinion. 
 
So I am interested to know if there are solid, TECHNICALLY SOUND opinions in 
favor of use of small relays. If running a small relay is just for feeling good 
and displaying political support for privacy rights, then I am outta here. I 
feel good already and I have other means of expressing my political support.
 
Rana
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] What's a "useful" relay?

[Rana]

So - what's the metric for calling a middle relay "useful"? Is it the total
number of bytes that it relays daily? 
https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C
C6 is sending about 0.85 GB every 24 hours. Is it a "useful" relay?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

Thank you @Gamby for echoing my sentiment. 

While there can be a good tech reason for considering small relays useless, the 
small relay operators MUST be properly and openly advised about how useful or 
useless their relays are. I even have read about someone's suggestion of 
gamification of such feedback - which I think is a damn good idea , eg give 
people badges based on how USEFUL their relays are.

I heard here an idea that it's good that a lot of people run relays because 
their joining the party increases the size of the crowd that supports privacy. 
Well, a global crowd of 7000 is a pathetically small one considering the 
target, and people should run relays not because this makes them feel good 
about themselves but because they are convinced that their relays are being 
USED for a good purpose. If the small relays are largely unused (eg if 10% of 
the relays carry 90% of the Tor traffic - does anyone have an exact statistics 
on this?) and if, in addition,  there is no increased anonymity benefit in 
having a lot of small relays, then why bother? 


-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Gumby
Sent: Friday, December 23, 2016 6:06 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

I have followed this for some time with interest, because I've run 2 relays 
from "home" connections for over 2 years - at on point three, all on unused 
older laptops. I have an Archer C7 which can handle 31k connections 
(theoretically) and have never had issues. My IP address changes maybe 3 times 
a year.
I am set at 1 mb up/down - largely unused compared to its capacity, but I 
really don't care as long as it runs. I have had as many as 3700 connections 
but usually 150 or so. I still do not care - I have felt that this still 
provides for someone, somewhere.
I will continue, without getting upset over unused "horsepower". 
With that said however - if the authority feels I am pathetically useless 
(reminds me of the testosterone ego of high school jocks) then what would 
happen if all the small relays - like me - say piss on it? At what point does 
this entire Tor freedom concept become the field of rich, unlimited bandwidth 
mavens?

And incidentally, those jocks would never had graduated if not for the "nerds" 
that tutored them - the little guys provide a hell of a lot more than people 
realize.

Gumby

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

@grarpamp

>Please see and contribute to the following...
>https://trac.torproject.org/projects/tor/wiki/doc/HardwarePerformanceCompendium

The Pi info there is indeed totally out of date. I opened an account on the 
wiki. However, after 10 (!)  tries to pass the totally unnecessary captcha 
which blocked my access AFTER I logged in, I have given up on trying to upload 
my data there. 

>If the source code and network technically permits any given node, it is valid 
>for discussion.

Not only the network and code permit Pi-based relays from residential premises 
with ANY kind of Internet connection bandwidth, the texts on Tor page encourage 
people to run relays without telling them that their relays may be unwanted or 
useless if their connection is not fast enough. I have no firm data on this but 
my gut feeling is that the use of small residential relays can be optimized and 
made useful; and if it can't as some knowledgeable people on this forum seem to 
opine, then this info should be openly available for all and not just for the 
initiated or for people like me who spend the time to dig into the discussion 
on this forum for 3 weeks in order to find this out.  

>I've often suggested that all node selection and testing / ranking / node 
>trust pki metrics / geoip / etc all be left as subscription style services 
>and/or configurable parametrics for clients to >choose from or configure 
>themselves. With some default "Tor Project" set shipped as fine for most 
>users, in which Tor Project acts as one such supplier of such params.
>That leave only malacting nodes and 'net useful' nodes up to dirauths 
>themselves. With 'useful' being no excuse to not make efforts to scale 
>networks to the next level.

I could not agree more.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

If there is such a wiki I will be happy to submit my reports, I am not aware of 
one. Also, based on this thread the people who may take action and decisions 
seem to be convinced that home relays are of no or very little use to Tor. For 
this reason, whether they are right or not, I am not sure we should bother 
beyond the unstructured discussion in this thread.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
grarpamp
Sent: Thursday, December 22, 2016 8:37 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

On Thu, Dec 22, 2016 at 4:59 AM, Rana <ranaventu...@gmail.com> wrote:
> A 20 mbps Pi relay has been reported here, still under-utilized.

All these reports of this or that made in piles of random email ...
serves no one past the typical few day participant convos.

So please people... submit all your hardware speed reports to the wiki in some 
organized tabular and broken out for descriptive commentary doco fashion so 
others can refer to it as a useful resource.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of David Serrano
Sent: Thursday, December 22, 2016 7:36 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic
IP

On 2016-12-22 19:24:25 (+0200), Rana wrote:
>>  
>> 2. "Residential lines in particular ... hardware caves when too many 
>> connections are open in parallel" - this appears to be plain 
>> incorrect. [...] ith 1300 simultaneous connections.

>His statement is right. 1300 connections are not a lot. I used to have a
symmetric 20 megabytes/second line and the router provided by my ISP would
reboot when reaching around 3600 >connections. Happily, they provided FTTH
so I was able to put a linux box instead of said router and reach 13k conns.

You are a part of a minuscule group of people who have a 160 mpbs symmetric
connection to the home, and the first one I run into in my life. I therefore
doubt that your example is relevant to the discussion - almost everybody
else on the planet does not have this kind of bandwidth to the home, and
cannot saturate a $35 Raspberry Pi with his Tor traffic because their
bottleneck is ISP bandwidth, not hardware. Which was my point.


--
 David Serrano
 PGP: 1BCC1A1F280A01F9

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

@Sebastian,
 
Thank you for the detailed presentation of your arguments against the use of
residential relays. While many (probably most) of the points you made are
convincing and, coming from a DirAuth operator, difficult for me to contest,
I would like to refer to those of them that seem to be less firm to me (I am
not referring to the "political support" argument here, my points are purely
technical):
 
1. If DirAuths are no longer the bottleneck , and the bottleneck shifted to
the distribution of information about new relays, maybe it is the next
problem that should be looked at and resolved by the Tor developers.
 
2. "Residential lines in particular ... hardware caves when too many
connections are open in parallel" - this appears to be plain incorrect. A Pi
based relay was recently reported here by @balbea that has 20%/60%
CPU/memory utilization, respectively, 21 mbps (measured) peak/900 kbps
(measured) average utilization by Tor, with 1300 simultaneous connections.
The speed @balbea could squeeze out of his residential ISP is pretty amazing
and, despite my call on this forum for further examples, unbeated and, to
the best of my knowledge, all but unprecedented. And that's at 60%
utilization of the bottleneck resource - the memory and the obvious
under-utilization by Tor.  If anybody's residential relay "caves" he should
get a $35 Raspberry Pi and - yay - no more caving hardware.
 
3. "the connection (which most often is asymmetric, with less upload
capacity than down) were any near saturated using the internet would become
a horribly slow and unpleasant experience" - I see no problem whatsoever to
engineer  the use of bandwidth to 50% or 40% of the peak down  BW available
to the relay, so that this problem will never happen. After all, every Tor
instance does a bandwidth self-test and knows what's its peak down capacity.
So this appears to be a non-issue (or maybe an issue that was "neglected by
design").
 
So again, many of your arguments are convincing but there appears to be room
for re-engineering the parts of Tor that deal with small relays, to get a
greater benefit from them.
 
Moreover, there seems to be a disconnect between what I read, including on
official Tor site, and the true state of affairs with small relays as
presented by you. You are obviously a knowledgeable guy, and a member of the
team that actually runs Tor and makes decisions. This makes me take your
statement that running a small bridge is actually harmful, very seriously.
 
Therefore, based what you say, my logical conclusion is as follows: the best
thing for Tor would be as many people as possible running exits; but since
this is beyond the risk most people are willing to take, the next best thing
is running a BIG and stable guard or a BIG and stable bridge. The lowest
priority is a bandwidth-wise small (even if stable) residential relay or a
small bridge, to the extent that these (the small ones) are not really
needed and are actually likely to do damage by  overloading the Tor
descriptor distribution mechanism or screwing up the way people use bridges,
respectively.
 
Which makes me wonder - why aren't there clear guidelines on Tor site about
this? I have read there (I do not remember on which page) the following
recommendation (or rather, a call for action with an exclamation mark): "If
you cannot be an exit, be a relay. If you cannot be a relay, be a bridge!"
This is obviously addressed to people who do not have intimate knowledge of
Tor and may be just about to make a decision to run a node. Nobody tells
them that they should not run a bridge or a relay if they are on residential
premises, let alone that this could actually do more damage than good.
 
Rana
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

@Andreas
...
>> I realize there could be pros and contras. Among the contras there could be 
>> (for example) many small relays overloading the dirauths. I would like to 
>> hear more about the contras.
>A Pi running at its line speed isn't exactly a small relay.

Of course it isn't.  A 20 mbps Pi relay has been reported here, still 
under-utilized.

...
> Additional info about my experiment: I have just fired up an additional relay 
> on Pi Zero. That's a fucking $9 Tor relay, including flash card and case.  
> Looks like an oversized USB stick and plugs directly into a USB port of a 
> computer. No need even for power supply.

>Why wouldn't you run the relay directly on the connection/powering computer? 

As I said, it is an experiment to see if this is working at all and what's the 
performance. Also, it was easy - I could use my PC to ssh into the Pi via the 
USB port, and am running a relay through the same port, so no tinkering with 
hardware. Eventually the Tor relay stick could be plugged directly into a USB 
port of a home router, I believe that there are some that have such ports.

>Also, is the external USB network interface included in the pricing 
>calculation?

What external USB network interface? Pi Zero has a micro USB connector. All 
that is needed is a standard USB cable, not even OTG one, I fished an old one 
from my junkbox. If you want  you can add a whopping $1 to the cost :)

If you mean microUSB-to-Ethernet adaptor, that's $1.96 on eBay:

 
http://www.ebay.com/itm/1pc-Micro-USB-2-0-to-Ethernet-10-100-RJ45-Network-LAN-Adapter-Card-uk-/262593720059?hash=item3d23ce2efb:g:jHwAAOSwU-pXvqrT

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

@Patrice:

Yes both relays started with brand new identities and the one that is now 
clinically dead (nickname ZG0) has been wiped out and restarted with a new 
fingerprint AND a new IP address as I have a dynamic one and I rebooted my 
router to get a new one).

 Did not help, so obviously this has everything to do with the network and how 
dirauths/bwauths test the connection and vote, and absolutely nothing to do 
with the identity of the relay

See my previous messages to confirm that this has absolutely nothing to do with 
the capabilities of the Pi, which are a gross overkill for the use of 
(nickname) GG2 that the dirauths and bwauths allow. 


-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Patrice
Sent: Thursday, December 22, 2016 2:57 AM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] @Rana - with reference to: Unwarranted discrimination of 
relays with dynamic

Hi,

I`ve read your post and questions, also about your 2 Raspberry PIs with the 
same setting but different locations.
I thought about it and my question is:
Did these to PIs got a new fresh identity on day zero?
If not, it`s worth a try, probably. Kill the old identities and let them by.

My fundamental idea is (and that`s why I am writing this): Does my behaviour 
with the relay (restarting, upgrading, not be onlinening) effect the 
measurement and therefore the throughput of my relay?


Cheers,
Patrice
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Report of home relay experience (cont'd)

[Rana]

Of the two relays that I run from two different residential premises for
some time now, the first, nicknamed ZG0 (has absolutely stable dynamic IP
and Stable flag for many days now) is clinically dead despite the measured
BW of 100 kbytes/sec.
 
The second, nicknamed GG2 (static IP, Stable, Fast, HSdir) is not dead but
is relaying only about 0.5 gbytes per day. That's an average rate of just 4%
of its never-changing measured BW of 153 Kbytes/sec (which is equal to 100%
of its bandwidth limit in torrc). It currently has 900 connections and made
over 16,000 circuit handshakes in the last 6 hours, all of them successful.
 
The two relays run on identical Pies with the same configuration except the
bandwidth limit (which is higher on ZG0 than on GG2) and negligible CPU and
memory utilization.
 
Comments?
 
Rana
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Flags?

[Rana]

No. I have a dynamic address, my relay is clinically dead (nickname: ZG0) but I 
got a Stable flag and it never went away,
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
balbea16
Sent: Monday, December 19, 2016 2:53 PM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Flags?
 
Hi There, 
I assume, that this has been discussed here already pretty often. However, it 
seems to be, that the "stable flag" is only assigned to relays with a static, 
or at least long lasting, IP address. It also seems to be, that the stable flag 
is mandatory to get the guard flag. If so, that would mean: Dynamic address = 
no chance to obtain the guard flag. Is that the truth? 
Tnx 
Mike 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] asymmetry in connections

[Rana]

On one of my relays I have 389 inbound, 38 outbound connections and 15
circuits
 
What's the connection between these 3 numbers and why such asymmetry in
inbound and outbound?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Netflix overblocking non-exit Tor relays

[Rana]

In my experience this is a common enough phenomenon. Happened to me twice here. 
All kinds of sites employ “professional” services that keep them “safe” by 
letting them know when someone uses the service from a Tor address, or plain 
blocking such surfers. The problem is that these “professionals” simply read 
the Tor consensus and ignore the (non) existence the Exit flag in the nodes. So 
someone who runs a relay node from his home can be reported as “using Tor” 
because his home IP address is listed as running a node, even though his node 
does not have Exit flag.
 
Last time this happened to me it was with an online shop and the message I got 
on the screen an email address of the “security” service which I should contact 
to clarify the issue. Instead of doing so I used the domain name of the email 
address to identify the company, and then wrote to the online shop that their 
‘security” service provider is ruining their business by blocking and scaring 
away their online customers, falsely claiming that they use Tor. Half an hour I 
could access the site without a problem.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

Well I do suggest that you get a set of Pi heat sinks on ebay for $0.70 
(including postage from China, adhesive and sinks for all 3 chips on the Pi). 
And if you are as extravagant as I you will even shell out an additional $1.20 
for a Pi case. Your 20 mbps relay has some value, you do not want to step on it 
accidentally :)
 
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
balbea16
Sent: Thursday, December 15, 2016 10:24 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Tor relay from home - end of experiment?
 
You are totally right. Besides the "cost" for the PI, I pay some additional 
Euros per month for the 40 MBIT upload, that's it. I really can recomment to 
run a relay on a Pi 3. Let's see how the Tor authorities handle this.
 
By the way the CPU temperature levels around 60 Celsius  (without running arm). 
I don't cool it. 
Mike
 
 
Von meinem Samsung Gerät gesendet.


 Ursprüngliche Nachricht 
Von: Rana <ranaventu...@gmail.com <mailto:ranaventu...@gmail.com> > 
Datum: 15.12.16 08:53 (GMT+01:00) 
An: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org>  
Betreff: Re: [tor-relays] Tor relay from home - end of experiment? 
OK then let me summarize. 
 
1.   You are running a Pi from Cologne, at 21 mbps (measured) peak, 900 
kbps (measured) average utilization by Tor, with 1300 connections.
2.   Your Pi is under-utilized, probably limited by your ISP’s peering with 
those to which DirAuths are connected. 20% CPU utilization, 50% memory 
utilization. 
3.   Given that part of the memory is used by Linux kernel, and that the PI 
Ethernet interface is nominally 100 mbps, the Pi is probably able to sustain up 
to 3000 connections. 
 
Bottom line: the $35 Pi is a killer and running a Tor node with up to 3000 
connections on another computer is probably a big waste of money. Comments 
welcome.
 
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
balbea16
Sent: Thursday, December 15, 2016 9:04 AM
To: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> 
Subject: Re: [tor-relays] Tor relay from home - end of experiment?
 
Pls. refer to may answers after each of your questions.
 
 


 Ursprüngliche Nachricht 
Von: Rana <ranaventu...@gmail.com <mailto:ranaventu...@gmail.com> > 
Datum: 15.12.16 07:44 (GMT+01:00) 
An: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org>  
Betreff: Re: [tor-relays] Tor relay from home - end of experiment? 
>Hi There
>This is a pretty interesting topic. I have been running a Rasp Pi 3 based 
>relay since August this year. By now, I am up to about 1,300 incomming and 
>outgoing connections, and a max of >about 21mbps. This is about 50% of the 
>max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is 
>running at 20% max. However, my local ISP disconnects me after 24 >to 36 
>hours. From my point of view this is the only disadvantage. 
> 
>For a home based relay, is that good, bad,  or just average? Is there a chance 
>for me to get a stable, or even guard flag? What are your experiances?
>Mike
My experience is bad, the relay is not taking off at all, I have consensus 
weight of 19 and am sending less than 20 MB every 6 hours despite having 
bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I 
have in ISP connection is 1.5 mbps and this is probably the issue. I also run 
this on Pi 3. I did, however, get a stable flag after 5 days, and have had it 
since then. My IP is dynamic and did not change in these 5 days or in the 4 
days that passed since I got the Stable flag. My relay nickname is ZG0.
Based on your experience I think your are doing fabulously well for a home 
relay, and that what really counts is the ISP bandwidth, and the Stable flag 
does not have much to do with how much traffic you get. Moreover, your 20% cpu 
util confirms my opinion that Pi is the perfect, most cost efficient way to run 
a relay and that running it on a larger computer is a waste of resources and 
money (up to the point Raspi chokes which we are yet to discover :))
Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory 
size. You have a total of 1GB of memory on your Pi 3, what’s your memory 
utilization?  about 513 MB 
What’s the total traffic the Pi sends every 6 hours (reported in the Tor log 
file /var/log/tor/notices.log and, for the previous time window, in 
/var/log/tor/notices.log.1)? 
About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and 
received 2625.31 GB. 
What’s your relay’s nickname? Balbea16
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

OK then let me summarize. 
 
1.   You are running a Pi from Cologne, at 21 mbps (measured) peak, 900 
kbps (measured) average utilization by Tor, with 1300 connections.
2.   Your Pi is under-utilized, probably limited by your ISP’s peering with 
those to which DirAuths are connected. 20% CPU utilization, 50% memory 
utilization. 
3.   Given that part of the memory is used by Linux kernel, and that the PI 
Ethernet interface is nominally 100 mbps, the Pi is probably able to sustain up 
to 3000 connections. 
 
Bottom line: the $35 Pi is a killer and running a Tor node with up to 3000 
connections on another computer is probably a big waste of money. Comments 
welcome.
 
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
balbea16
Sent: Thursday, December 15, 2016 9:04 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Tor relay from home - end of experiment?
 
Pls. refer to may answers after each of your questions.
 
 


 Ursprüngliche Nachricht 
Von: Rana <ranaventu...@gmail.com <mailto:ranaventu...@gmail.com> > 
Datum: 15.12.16 07:44 (GMT+01:00) 
An: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org>  
Betreff: Re: [tor-relays] Tor relay from home - end of experiment? 
>Hi There
>This is a pretty interesting topic. I have been running a Rasp Pi 3 based 
>relay since August this year. By now, I am up to about 1,300 incomming and 
>outgoing connections, and a max of >about 21mbps. This is about 50% of the 
>max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is 
>running at 20% max. However, my local ISP disconnects me after 24 >to 36 
>hours. From my point of view this is the only disadvantage. 
> 
>For a home based relay, is that good, bad,  or just average? Is there a chance 
>for me to get a stable, or even guard flag? What are your experiances?
>Mike
My experience is bad, the relay is not taking off at all, I have consensus 
weight of 19 and am sending less than 20 MB every 6 hours despite having 
bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I 
have in ISP connection is 1.5 mbps and this is probably the issue. I also run 
this on Pi 3. I did, however, get a stable flag after 5 days, and have had it 
since then. My IP is dynamic and did not change in these 5 days or in the 4 
days that passed since I got the Stable flag. My relay nickname is ZG0.
Based on your experience I think your are doing fabulously well for a home 
relay, and that what really counts is the ISP bandwidth, and the Stable flag 
does not have much to do with how much traffic you get. Moreover, your 20% cpu 
util confirms my opinion that Pi is the perfect, most cost efficient way to run 
a relay and that running it on a larger computer is a waste of resources and 
money (up to the point Raspi chokes which we are yet to discover :))
Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory 
size. You have a total of 1GB of memory on your Pi 3, what’s your memory 
utilization?  about 513 MB 
What’s the total traffic the Pi sends every 6 hours (reported in the Tor log 
file /var/log/tor/notices.log and, for the previous time window, in 
/var/log/tor/notices.log.1)? 
About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and 
received 2625.31 GB. 
What’s your relay’s nickname? Balbea16
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

>Hi There
>This is a pretty interesting topic. I have been running a Rasp Pi 3 based 
>relay since August this year. By now, I am up to about 1,300 incomming and 
>outgoing connections, and a max of >about 21mbps. This is about 50% of the 
>max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is 
>running at 20% max. However, my local ISP disconnects me after 24 >to 36 
>hours. From my point of view this is the only disadvantage. 
> 
>For a home based relay, is that good, bad,  or just average? Is there a chance 
>for me to get a stable, or even guard flag? What are your experiances?
>Mike
 
 
My experience is bad, the relay is not taking off at all, I have consensus 
weight of 19 and am sending less than 20 MB every 6 hours despite having 
bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I 
have in ISP connection is 1.5 mbps and this is probably the issue. I also run 
this on Pi 3. I did, however, get a stable flag after 5 days, and have had it 
since then. My IP is dynamic and did not change in these 5 days or in the 4 
days that passed since I got the Stable flag. My relay nickname is ZG0.
 
Based on your experience I think your are doing fabulously well for a home 
relay, and that what really counts is the ISP bandwidth, and the Stable flag 
does not have much to do with how much traffic you get. Moreover, your 20% cpu 
util confirms my opinion that Pi is the perfect, most cost efficient way to run 
a relay and that running it on a larger computer is a waste of resources and 
money (up to the point Raspi chokes which we are yet to discover :))
 
Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory 
size. You have a total of 1GB of memory on your Pi 3, what’s your memory 
utilization?  What’s the total traffic the Pi sends every 6 hours (reported in 
the Tor log file /var/log/tor/notices.log and, for the previous time window, in 
/var/log/tor/notices.log.1)?
 
What’s your relay’s nickname?
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Sebastian Niehaus
Sent: Wednesday, December 14, 2016 2:43 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Tor relay from home - end of experiment?

Am 14.12.2016 um 11:46 schrieb Rana:

>>They do, however, have different numbers as to how much traffic they can 
>>carry; which in view of the above IMHO can be attributed only to the 
>>difference in how well their respective IPSs connect 
>>with the ISPs in places where DirAuths are located.
>What kind of connection are they attached to? DSL? Fiber? Cable?
>POTS/Modem? ... ?
DSL, both of them - but different ISPs. ZG0 has up bandwidth of 1.5mbps, GG2 
has 3mbps, both very table at these numbers

>What kind of hardware is used to build the connection? One of these shiny 
>pretty Netgear R7900?
DSL modem boxes  supplied by the ISPs. In case of ZG0, an ADB box. Why is this 
significant?

Rana



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

>Since the consensus weight is the low-median of 5 measurements spread around 
>the US and Western Europe, being in Germany only gets you one good 
>measurement: you need 3 good measurements >to get a high consensus weight.
>
>From https://en.wikipedia.org/wiki/Median :
>
> Because of this, the median is of central importance in robust statistics, as 
> it is the most resistant statistic, having a breakdown point of 50%: so long 
> as no more than half the data are contaminated, the median will not give an 
> arbitrarily large or small result.

I know what average, median and peak is, thank you for the lecture in high 
school math. The difference in the definitions of peak and average cannot 
possibly account for  the latter being 0.2% of the former in GG2, this ratio 
being pretty stable over the last 100 hours.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

>> A. The fact that the Authorities are located in West Europe and North 
>> America does not mean that the USERS are there.

>The question is what volume a relay can carry, and not how well it is 
>connected to a particular place in the world.

I beg to differ. My experiment with two identical Pies in the same country 
showed that the alleged volume that the relay can carry IS dependent on how 
well it is connected to the specific DirAuths (which represent "particular 
places in the world"). The fact is, the two nodes are HW/SW-wise identical and 
both have much more Internet connection bandwidth than the bandwidth allocated 
for Tor. They do, however, have different numbers as to how much traffic they 
can carry; which in view of the above IMHO can be attributed only to the 
difference in how well their respective IPSs connect with the ISPs in places 
where DirAuths are located.

>> B.  There are about 7000 relays total, many of them probably limping just 
>> like my 2 relays and not being useful. There are tens of thousands of Pi 
>> owners who have their Pis just sitting there and many >>of them would be 
>> happy to run relays if Tor network would let them do so usefully.
>
>I may soon have an opportunity to hook up a pi to a sufficiently large pipe. 
>(My home connection makes such things pointless.)

Your upcoming connection of a Pi to a large pipe is irrelevant to the issue 
reported by me, since clearly in my case the Pi is not the bottleneck. On the 
other hand, your parenthesized sentence is very relevant - it seems that you 
have given up on home based relay, too. I did see a report from someone 
boasting the large bandwidth via Pi at home - but this seems to be an exception 
rather than a rule, and he was in Germany, probably at a cozy digital distance 
from the local DirAuth :)

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

-Original Message-
>From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
>teor

> Your relay's observed bandwidth is
>ZG0: 81.35 KByte/s
>GG2: 170.79 KByte/s
>
> (hover over the
> bandwidth heading in atlas for these details), so its consensus weight 
> will be limited to approximately
>ZG0: 81
>GG2: 170
> Your bandwidth rate and burst are
>ZG0: 256 KByte/s and 358.4 KByte/s
GG2: 153.6 KByte/s and 179.2 KByte/s
>
>Your relay is limited by:
>ZG0: its own ability to sustain more than 81.35 KByte/s over a 10 second period
>GG2: the bandwidth rate of 153.6 KByte/s
>
>In summary:
>ZG0: the relay itself reports that it is unable to sustain much tor traffic.
>GG2: it appears that the relay could handle more traffic, if you increased the 
>bandwidth rate and bandwidth burst.

Both ZG0 and GG2 use exactly the same hardware and software (Pi with the same 
microsd card flashed), with the exception that ZG0's max bandwidth rates are 
actually configured to be HIGHER than those of GG2. 

Logical conclusion based on the above measurements: ZG0's poor bandwidth has 
absolutely nothing to do with the capabilities of ZG0 machine to sustain 
traffic. This can only have anything to do with its ISP and/or with the way the 
Authorities "treat" ZG0. Note that on both machines cpu utilization is 
minuscule and memory utilization is 12%.

Why, while GG2's speed as MEASURED by tor and reported in atlas is 153.6 
kbytes/sec, its actual bandwidth utilization is about 0.3 kbytes/sec (=0.2% of 
its capability) is still beyond me, and resolving this by further increasing 
bandwidth does not seem plausible to me.

>I feel like I've given the same advice about ZG0 several times now, so I'm 
>going to leave that with you to resolve however you want.

You and some others have been very helpful in educating me about what is going 
on, and for that I thank you. However, is described above, I am not anywhere 
near resolving the issue. The only conclusion is that I simply cannot run 
relays from home locations, because their use will be negligible, whatever I 
(reasonably) do.

This opinion was further supported by the reported two experiments with two 
identical Pi-based relay instances running at two different home locations with 
two different ISPs.

Among other things, I was given (I do not remember by whom) the explanation 
that the bandwidth ratings of my relays suck probably because they are measured 
from where the Authorities are located, and my connection to THESE locations 
may not be good. This may well be the correct explanation that reaffirms my 
conclusion that all I can do with my two relays is ditch them.

I want to reiterate my opinion that Tor network is "mistreating" home-based 
relays without good reason:

A. The fact that the Authorities are located in West Europe and North America 
does not mean that the USERS are there. I would suggest quite the opposite: the 
users that REALLY need Tor are NOT located in these countries. Bandwidth 
measurements should be performed, among others, from where the most needful 
users are located, not only from democratic countries that host DirAuths. While 
I understand why DirAuths need to be located in safe places, I see no reason 
for bwauths that measure the bandwidth to only be located there. DirAuths are 
not disposable, bwauths are.

B.  There are about 7000 relays total, many of them probably limping just like 
my 2 relays and not being useful. There are tens of thousands of Pi owners who 
have their Pis just sitting there and many of them would be happy to run relays 
if Tor network would let them do so usefully. Not using this huge resource by 
discriminating against relays that are behind dynamic IPs or because they 
happen to have a poor connection to, say, Germany, does not make sense to me.

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay from home - end of experiment?

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Sebastian Niehaus
Sent: Tuesday, December 13, 2016 9:07 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Tor relay from home - end of experiment?

Am 13.12.2016 um 20:01 schrieb Rana:

>> Any other advice / ideas welcome.

>You have been asked for fingerpring or atlas link several times.

The nicknames of the two relays are ZG0 and GG2, respectively


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor relay from home - end of experiment?

[Rana]

After 9 days of running a relay with a stable IP address (with "Stable" flag
during the last 4 days) and consensus bw steadily oscillating around 20
despite the 100 Kbyte/s bandwidth measured by Tor and 200 Kbyte/s bandwidth
measured on the Internet connection, I guess it is time to quit. My relay is
consistently sending less than 20MB every 6 hours, which probably means that
is not making a noticeable contribution to Tor network.
 
I have also been running another relay for the last 5 days from a friend's
home - he has a static IP, a different ISP from mine and twice the
bandwidth. His consensus is bw dead locked at 31 and never changes. He is
getting Fast flag on and off, no Stable flag, his Atlas measured bandwidth
is 150 KB/s. The traffic it relays is only slightly larger than mine, so I
guess it is time to quit for this one, too.
 
Any other advice / ideas welcome.
 
Rana
 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[Rana]

> On 12 Dec. 2016, at 01:56, Rana <ranaventu...@gmail.com> wrote:
> 
> OK Tim thanks for the answers, I appreciate your patience with me 
> [even though I "lack programming skills" :) ]
> 
> The one answer of yours that still does not make sense to me is that 
> arm actually means Kbytes/sec and not kbits/sec  when it writes Kb/s
> 
> I have arm reporting average  of at least several tens of Kb/s all the time, 
> and about 100 Kb/s most of the time,  and then I wind up with almost constant 
> 200 bit/sec actual average rate over 6 hours, based on the total number of 
> Mbytes sent that Tor reports in its log file. 
> 
> Even if the 200 bit/sec figure is somehow rounded to 8000 bit/ sec or 
> even 8000 bytes/sec as you suggested , this does not make sense…

Ok, so you didn't say that to start with, you seemed to be saying that it was 
constantly showing 100 kb/s.

Perhaps arm is displaying your maximum bandwidth over a certain time?
(I really don't now what bandwidth arm measures.)

T

I do not have a slightest freaking idea and this arm thing seems to have been 
written by anarchists who thought that documentation was too bourgeois

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[Rana]

OK Tim thanks for the answers, I appreciate your patience with me [even though 
I "lack programming skills" :) ]

The one answer of yours that still does not make sense to me is that arm 
actually means Kbytes/sec and not kbits/sec  when it writes Kb/s

I have arm reporting average  of at least several tens of Kb/s all the time, 
and about 100 Kb/s most of the time,  and then I wind up with almost constant 
200 bit/sec actual average rate over 6 hours, based on the total number of 
Mbytes sent that Tor reports in its log file. 

Even if the 200 bit/sec figure is somehow rounded to 8000 bit/ sec or even 8000 
bytes/sec as you suggested , this does not make sense...

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[Rana]

>> On 10 Dec. 2016, at 07:12, Rana <ranaventu...@gmail.com> wrote:
>> 
>> My relay remains severely under-used. One thing that bothers me are 
>> inconsistent bandwidth measurements. Here they are: 
>> Atlas “advertised” (which is actually supposed to be “measured”?:   100 KB/s 
>> = ~ 800,000 bit/s
>
>This is the minimum of:
>* the bandwidth rate,
>* the bandwidth burst, and
>* the observed bandwidth (the maximum bandwidth your relay has recently
> sustained over a 10 second period).
>* the consensus weight, converted to a bandwidth figure (I think?).
>
>If you hover over the figure in atlas, it will break it down for you.

Thanks for the tip. It says it is the actually measured bandwidth

>
>> “I have sent” reported in Tor log: on the average pretty stable 17 mbytes 
>> every 6 hours =   ~ 200 bit/s
>
>This is what your relay has actually sent.

Totally inconsistent with the rest

>> Atlas graphs:  1 Kbytes/s  on the average
>>   ~ 8,000 
>> bit/s
>
>This is the value that your relay reports it has sent.
>It is rounded and averaged to preserve client privacy.

This is not consistent with the 200 bit/s figure. Do you mean to say that Atlas 
rounds 200 bps on the average to 8000 bps on the average?

>> Consensus BW: 26 =   
>>  
>>~ 26,000 bit/s

>This is the low-median of the measurements of the 5 bandwidth authorities. It 
>is a dimensionless figure that only makes sense when compared with other relay 
>consensus weights.

Can't comment because I have no idea what the formula is, therefore this figure 
is meaningless to me.


>> Average upload bw reported by arm: 100 kb/s =
>>  ~ 100,000 bit/s

>I suspect this is actually kilobytes, and is the same as the atlas figure. 
>(They use the same backend library.)

This would not be consistent at all with actual reported upload of 17 mbytes in 
6 hours which as I said is pretty constant. The ~100 Kb/s average bit rate 
figure reported by arm lingers for HOURS. This rate,s 17 MB would have been 
sent in THREE MINUTES. If the rate were 100 kbyte/s as you suggest then it 
would take the relay 22 SECONDS to send what it claims it is sending in 6 hours.

>> Makes zero sense.

Still doesn't. Why do Tor and Tor-related projects such as arm  publish all 
these TOTALLY inconsiostent figures? If they want to confuse the adversaries I 
doubt that it worked, but they sure as hell were highly successful in confusing 
me :)


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Inconsistent BW measurements of unused relay

[Rana]

My relay remains severely under-used. One thing that bothers me are
inconsistent bandwidth measurements. Here they are:
 
 
Atlas "advertised" (which is actually supposed to be "measured"?:   100 KB/s
= ~ 800,000 bit/s
"I have sent" reported in Tor log: on the average pretty stable 17 mbytes
every 6 hours =   ~ 200 bit/s
Atlas graphs:  1 Kbytes/s  on the average
~ 8,000 bit/s
Consensus BW: 26 =
~ 26,000 bit/s
Average upload bw reported by arm: 100 kb/s =
~ 100,000 bit/s
 
Makes zero sense.
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Connections from UNKNOWN relays

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: Saturday, December 10, 2016 2:54 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Connections from UNKNOWN relays


>> On 10 Dec. 2016, at 23:05, Rana <ranaventu...@gmail.com> wrote:
>> 
> >Arm shows that my middle relay has incoming connections from UNKNOWN relays 
> >(no consensus data on them at all except locale). Are these bridges?
>
>Possibly, or they are relays that are not in the current consensus, but are in 
>a consensus still being used by a client. (Clients will use consensuses up to 
>27 hours old, there is one consensus per hour.)

Assuming most of these are bridges, this could be a vulnerability as this 
allows rogue middle relays to enumerate bridges.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Connections from UNKNOWN relays

[Rana]

Arm shows that my middle relay has incoming connections from UNKNOWN relays
(no consensus data on them at all except locale). Are these bridges?
 
There is also one outgoing connection to UNKNOWN but the address of that is
0.0.0.0:0
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Belarus (finally) bans Tor

[Rana]

https://ooni.torproject.org/post/belarus-fries-onion/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
grarpamp
Sent: Friday, December 09, 2016 11:18 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Exploiting firmware

>>> Intel ME/AMT concerns me too

>> AMD Family 15h itself is safe.

>No one has any proof of that for any modern cpu from any maker, featureset 
>irrelavant. They all accept microcode updates, which btw are all encrypted 
>closed binary blobs. And the chips themselves are fully closed >source 
>containing billions of transistors. You simply have no idea what's in there 
>and no way to economically and publicly test or negotiate to find out and 
>openly publish it all.

>Talking about known shit like advertised ME/AMT + LM-NIC's corp management 
>platform is fine, you might be able to mitigate.
>But it's the unknown that will kill you.

>Billions of secret transistors... billions.
>Not good, and not necessary.

Agreed. Effort spent on guessing which closed source processor is safe is a 
wasted effort, and any conclusion that a certain processor is "safe" is a 
dangerous delusion resulting in flawed threat models. Just modify your threat 
model with the compromised processor assumption, calculate the risk of your 
specific computer being targeted, mitigate to the extent possible and get on 
with your life.

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Rana]

As long as CPU hardware is closed source, perfect privacy does not exist, full 
stop. Conspiracy theories are futile, the probability of microcode backdoor is 
1. So there is no need to "worry" about hardware blobs. There is NO way that 
processors made by US chip manufacturers do NOT contain a backdoor. The same 
goes for Raspberry Pi which is based on a Broadcom chip. 

Privacy is a therefore probabilistic entity.  Instead of worrying about 
hardware blobs, you should is try to estimate  the cost of intrusion, 
collection and analysis, divided by the probability of yourself being a target. 
This yields a weighted cost of spying on you. If the result is high enough, no 
problem, as the adversary's budget s always limited. Otherwise you are toast, 
Tor or no Tor, VM or no VM. What Tor hopefully does is raise the cost and thus 
minimize the probability of the Tor user being targeted, collected and 
analyzed, due to purely budgetary reasons.

I am happily using hardware based on Intel chips. If I were an ISIS ringleader, 
I wouldn't. Allahu Akbar but my ass is valuable, too.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is there a reason for all exit nodes being public?

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Paul Syverson
Sent: Wednesday, December 07, 2016 4:34 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Is there a reason for all exit nodes being public?

On Wed, Dec 07, 2016 at 02:15:55PM +0200, Rana wrote:
>>As of last April, FaceBook reported over a million users per month via Tor. 

I am sure that the 1 million FB users connect via Tor not because they want to 
hide their location but the want to hide WHO they are. Hence their 
authentication information is mostly false and they use Tor for personal 
anonymity, not for anonymous routing. 

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Anonymous email (was: Is there a reason for all exit nodes being public?)

[Rana]

>
>Protonmail supports receiving a verification code by email. Use a disposable 
>email provider that isn't blocked to receive the code. I _just_ made a 
>protonmail account to test.
>
>https://10minutemail.net/ worked for me just now.
>
>https://10minutemail.com did not work as protonmail recognized the address I 
>got from it as being temporary.
>
>Hope that helps.
>
>Matt

I already had it solved but I tipped a friend about https://10minutemail.net 
and it worked for him, for which he thanks you. I wonder how long it will take 
Protonmail to close this loophole :)

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is there a reason for all exit nodes being public?

[Rana]

>>> By the way, I just checked, Gmail works without problems over Tor (both Web 
>>> and IMAPS).
>> Using Gmail over Tor when they already know who you are is self-defeating. 
>> Try to register an anonymous Gmail account using Tor.

>Doable. They require a phone number for verification, but that's the same with 
>and without Tor. Besides, if you want an anonymous email, use _anything but 
>Gmail_, eg. ProtonMail.

Providing you phone number during registration = registration is not anonymous, 
so anonymous registration of a Gmail account using Tor is NOT doable. 

Last time I tried, this did not work. I provided the SMS number in a Tor 
registration attempt and Gmail said we cannot register you "at this time", 
without even trying to send me an SMS.

Protonmail is exactly the same thing, if you want to register a free account 
you need to provide your phone number. You can register "anonymously" in 
ProtonMail only for paid account, and even if you are willing to pay for 
anonymity, you need to pay in bitcoin which ultimately discloses you identity - 
so again, not anonymous.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is there a reason for all exit nodes being public?

[Rana]

On Wed, Dec 07, 2016 at 11:51:34AM +, Matthew Finkel wrote:
>> On Wed, Dec 07, 2016 at 01:25:59PM +0200, Rana wrote:
>> > I mean, why aren't some exit nodes kept hidden, at least partially 
>> > and temporarily, like bridges? This would mitigate web services 
>> > denying service to Tor users (Gmail is the most recent example), 
>> > plus would increase security.
>> 
> I'll simply refer you to the FAQ:

>That was rude of me, answer below. Do you disagree with the reasoning?

That was not rude at all, thank you for the reference to the FAQ. I largely got 
a satisfactory explanation there although points (b) and (c) might be 
controversial. 

The one point I find difficult to agree with is "(a) We can't help but make the 
information available, since Tor clients need to use it to pick their paths." 
If bridges can be hidden and provided to clients on as-needed basis, so can 
exits.

Rana



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is there a reason for all exit nodes being public?

[Rana]

>How would that work? First of all, the clients need to know which exit nodes 
>exist, so that they can build circuits. That list, as well as that of the 
>middle nodes, is public, otherwise you'd >have to manually request exits by 
>email/web service/… As a result you'd be limited to a few exits, which might 
>not necessarily have an exit policy matching your needs, or might be offline, 
>>or simply overloaded on account of there being less than regular exits.
The same way bridges work. They are not published.

>By the way, I just checked, Gmail works without problems over Tor (both Web 
>and IMAPS).
Using Gmail over Tor when they already know who you are is self-defeating. Try 
to register an anonymous Gmail account using Tor.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

There's an alternative interpretation but mentioning in reply to your message 
would be... rude :-)

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Ralph Seichter
Sent: Wednesday, December 07, 2016 12:59 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

On 07.12.2016 10:56, Rana wrote:

> Calling "rude" people who, to make a point, use a bit of obvious and 
> harmless humor, is rude.

Your getting on other people's nerves must *obviously* be the fault of other 
people. Welcome to Trump World. :-)

-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Is there a reason for all exit nodes being public?

[Rana]

I mean, why aren't some exit nodes kept hidden, at least partially and
temporarily, like bridges? This would mitigate web services denying service
to Tor users (Gmail is the most recent example), plus would increase
security.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

Calling "rude" people who, to make a point, use a bit of obvious and harmless 
humor, is rude.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Duncan Guthrie
Sent: Wednesday, December 07, 2016 11:41 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

On 07/12/16 05:32, Rana wrote:
> I can just imagine someone panting while dragging a sub-$35 old desktop 
> computer up the stairs after physically searching for it in a nearby 
> junkyard. A considerable level of destitution and a commendable commitment to 
> the cause of Tor  would be required.
This is hardly the case. Computers are so widespread that an old desktop system 
with even twice the power of the Pi can be had for buttons.
There is no need to be rude about the suggestions that people on this list make.

Duncan
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relays with dynamic IP - here Rasp2

[Rana]

>> Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's 
>> sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 
>> Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
> 
> It is just 1 single Rasp2 - running 2 tor instances on 1 IP, details 
> here 
> https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create.8.txt

Any specific reason you have for running 2 instances of Tor on the same Raspi 
instead of one?

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

I can just imagine someone panting while dragging a sub-$35 old desktop 
computer up the stairs after physically searching for it in a nearby junkyard. 
A considerable level of destitution and a commendable commitment to the cause 
of Tor  would be required.
 
-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Roman Mamedov
Sent: Wednesday, December 07, 2016 7:08 AM
To: Duncan Guthrie
Cc: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

On Wed, 7 Dec 2016 00:36:15 +
Duncan Guthrie  wrote:

> My original figure may have been... somewhat off. With different 
> models they may have updated the network hardware.

They did not. All models with Ethernet use the same SMSC LAN9514 chip.

> A more general point is that old desktop computers still offer better 
> performance than a Raspberry Pi. You can easily get one for 
> considerably less than the cost of a Pi

And pay more than the cost of a Pi in electricity.

--
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Circuits from Tor relay?

[Rana]

That's a thorough and useful answer. Thank you Tim.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: Wednesday, December 07, 2016 12:12 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Circuits from Tor relay?


> On 7 Dec. 2016, at 08:07, Rana <ranaventu...@gmail.com> wrote:
> 
> Arm reports that my relay has 15 circuits connected to my (middle only) 
> relay. Some of the circuits have one middle relay and some of them have two. 
> All the circuits are FROM my relay to exit nodes, and all have the same guard 
> (first) relay.

Your relay is testing whether its ORPort and DirPort are reachable from the 
internet. To do this, it uses a Tor Exit circuit to connect to the DirPort, and 
uses a Tor internal circuit to connect to the ORPort.
 
> My relay has a small number of inbound connections and a minuscule number of 
> outbound connections (it is a very new relay as I wiped out and restarted my 
> old one a day and a half ago). Most of the inbound connections are from 
> DurAuths.

The Directory Authorities are testing whether your relay is reachable from 
their IP address. To do this, they connect directly to the ORPort.

Also, the Bandwidth Authorities are testing what amount of traffic your relay 
can handle. They uses a Tor Exit circuit that goes via your relay and an Exit.

> What are all these circuits??? Why would a middle relay build full circuits 
> to exit nodes?

Like Tor clients, your relay also builds various circuits preemptively, in case 
it needs them later.

If you want more specific help, please provide the following information to the 
list:

What do the logs on your relay say?

What is your relay's fingerprint?
(Your relay is publicly listed in the tor consensus. If you want to keep the 
details private, run a bridge relay.)

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Circuits from Tor relay?

[Rana]

Arm reports that my relay has 15 circuits connected to my (middle only)
relay. Some of the circuits have one middle relay and some of them have two.
All the circuits are FROM my relay to exit nodes, and all have the same
guard (first) relay.
 
My relay has a small number of inbound connections and a minuscule number of
outbound connections (it is a very new relay as I wiped out and restarted my
old one a day and a half ago). Most of the inbound connections are from
DurAuths.
 
What are all these circuits??? Why would a middle relay build full circuits
to exit nodes?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

-Original Message-
>From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
>Duncan Guthrie
>
>Keep in mind also that the Raspberry Pi (at least the first one anyway) can 
>only push around 1MB/s tops. The ethernet port is basically held on by the 
>equivalent of a piece of string! >They're suitable for a small mail or web 
>server, or some sort of network probe, but not really for any large 
>application.
>
>Duncan

I am pretty sure your info is out of date. The $35 Raspi3 has four 1.2 GHz 
cores and 1GB RAM. On my Raspi (that admittedly does not see much traffic) CPU 
utilization hovers somewhere around 1% and total memory utilization by Tor and 
the rest of Linux together is 11%. Which is irrelevant since Tor network will 
not let it even near 1 mbit/s because - I believe - of its dynamic IP

I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths 
(or bwauths or whatever)  to come even near 1 mbit/s bandwidth utilization

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

>
>I think it would be interesting see as to whether allowing bridges to have 
>dynamic IPs (or even encouraging it) would make them harder to block, and 
>would make it really easy for people >to contribute to the network in this 
>small way? Or at least, having a mostly dynamic IP - some devices change their 
>IP address more frequently than others, if my understanding is correct?>
>
>Duncan

I have heard this theory before and I do not believe it is correct. The dynamic 
IPs do not change every hour, it usually takes many days or even weeks. So the 
contribution of IPs being randomly changed to the difficulty of their 
enumeration by censors would be marginal at best.

This COULD be useful if DirAuths would (a) stop punishing relays behind dynamic 
IPs (b)  start campaigning and encouraging people with dynamic IPs and  Raspis 
to run bridges and (c) raise the reputation of the bridges behind dynamic IPs  
according the novelty of their IP. 

So bridges with more recently changed IPs would get a higher priority in 
getting bridge traffic. Combined with intelligent assignment of either obfs4 or 
meek this would screw the Chinese (and soon the Russian) censors over big time, 
because they would be chasing an elusive army of Raspis with ever changing 
IPs...

Counter-attacks and counter-counter-measures should be studied though, as 
adversaries could respond by establishing hundreds of rogue bridges with 
dynamically changing IPs...

Rana




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

That was exactly my point, thank you Anemoi. This is the case all over the 
world, not just in Germany. Unfortunately there seems to be a culture of 
shooting the messenger here, or accusing him of being “aggressive”, 
“accusatory”, “claiming entitlement”  or (my favorite) “lacking programming 
skills”, in addition to politely phrased suggestions to ditch my relay and  pay 
for a VPS with a fixed IP. 
 
The idea of running a volunteer based network for public good is to use every 
possible resource offered by volunteers, and if DirAuth algorithms need to be 
adapted for this, such proposal should be taken seriously. I for one am 
positive that a huge amount of bandwidth that could have been be donated, is 
lost this way.
 
If this does not make technical sense (which I doubt but I may be wrong), 
rephrasing the guidelines and officially saying on the Tor page that operators 
behind dynamic IP are only welcome if they run bridges would be fine – but this 
isn’t not the case as of now. I hope Tor developers or whoever runs the Tor 
project are reading this.
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
ane...@tutanota.de
Sent: Sunday, December 04, 2016 9:24 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
 
In Germany, it's quite usual that you have a dynamic IP and unusual that you 
have static IP. Not just a few relays are located in Germany.  It's not just a 
question of frustration of owners of dynamic IP relay, but also a matter of 
bandwith waste. If Tor cannot handle dynamic IPs properly a lot of bandwith is 
not used. And bandwith is something that the Tor network can not get enough of. 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

Wow, I cannot think of a way to check the max number of connections on my 
router. I do not believe that Pi has such limitation...


-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: Sunday, December 04, 2016 11:42 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP


> On 5 Dec. 2016, at 08:15, Rana <ranaventu...@gmail.com> wrote:
> 
> My international connectivity is just fine, connection speed is stable at 1.5 
> mbps and I have a Stable flag. Three authorities voted to give me HSDir and 
> Fast. I have provided my Torrc. My consensus weight is stable for several 
> days now, at 14.

Speed tests don't test the things tor needs.

The 5 tor bandwidth authorities say your relay can't handle much bandwidth. 
They say it can sustain around 14KB/s when they check.

This might mean your Pi or your broadband router is overwhelmed with too many 
connections. Do you know what the maximum connection capacity is on your router 
and your relay?
Can you increase it to at least 8000?

Or it could be that your latency to Europe and North America is high.
(Relays in Asia, Australia, and New Zealand have similar issues.)

Tim


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

OK thanks, this is beginning to sound logical. What you are saying - correct me 
if I am wrong - is that since 3 DirAuths gave me fast/hsdir flags while the 
other 5 didn't and gave me poor weight, you believe that my connectivity with 
the 5 auths is poor and this is the source of my trouble. 

If you are right then there is no problem with my relay, no problem with my 
ISP, and there is a problem somewhere between the countries, and this problem 
hits specifically my relay. This last piece does not make sense to me but who 
knows...

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: Sunday, December 04, 2016 11:34 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP


> On 5 Dec. 2016, at 08:11, Rana <ranaventu...@gmail.com> wrote:
> 
> 5kbit/s traffic and consensus weight of 14 after running for a month, 
> including last 9 days with the same IP and a Stable flag - you consider this 
> normal?

No, sorry, I explained poorly:

Your maximum bandwidth is as expected for a middle relay with a similar config. 
The relay flags are as expected.

Your measured bandwidth is not, and indicates an issue with your relay's 
connectivity to the bandwidth authorities (5 tor clients/relays spread around 
Europe and North America).

Until you fix this issue, your relay will continue to be measured low, because 
it can not sustain the traffic the tor network needs.

It has nothing to do with your IP address changing.

Also, it's probably worth mentioning that the Tor network prioritises
*client* bandwidth, latency, and security. There are engineering trade-offs 
between these factors.

Using all available relay bandwidth is not a priority: we will happily use less 
bandwidth to provide better latency or better security.

Tim

> -Original Message-
> From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On 
> Behalf Of teor
> Sent: Sunday, December 04, 2016 10:52 PM
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] Unwarranted discrimination of relays with 
> dynamic IP
> 
> 
>> On 5 Dec. 2016, at 02:39, Rana <ranaventu...@gmail.com> wrote:
>> 
>>> For as little as $10.00 US there are VPS' with static ip's..
>> 
>> Attn: Kurt Besig
>> 
>> Well I kind o' like my Raspberry Pi that cost me $40 including box and power 
>> supply and SD card and door to door delivery, with far more horsepower and 
>> memory than needed for running Tor relay, and my free and absolutely stable 
>> 1.5mbps that I want to donate to Tor courtesy of my ISP, and my transparent 
>> Tor proxy and my hidden service  and my wireless access point that lurk on 
>> the same Pi. 
>> 
>> This is not a good reason to punish my relay. Makes ZERO sense to me and to 
>> who knows how many people like me whose relays are flushed down the drain by 
>> the current DirAuth algorithms.
>> 
>> I can think of many an Iranian or Turkish or Chinese or Russian dissident 
>> who could use 1.5 mbps bandwidth to communicate with the free world.
> 
> Rana,
> 
> Your relay is actually getting about as much traffic as a middle relay of 
> that size should expect.
> 
> When you change the IP address, it takes a while to re-establish that 
> traffic, as it should, due to the reasons I mentioned in my original email.
> 
> T
> 
> --
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B 
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> --
> --
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

5kbit/s traffic and consensus weight of 14 after running for a month, including 
last 9 days with the same IP and a Stable flag - you consider this normal?

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: Sunday, December 04, 2016 10:52 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP


> On 5 Dec. 2016, at 02:39, Rana <ranaventu...@gmail.com> wrote:
> 
>> For as little as $10.00 US there are VPS' with static ip's..
> 
> Attn: Kurt Besig
> 
> Well I kind o' like my Raspberry Pi that cost me $40 including box and power 
> supply and SD card and door to door delivery, with far more horsepower and 
> memory than needed for running Tor relay, and my free and absolutely stable 
> 1.5mbps that I want to donate to Tor courtesy of my ISP, and my transparent 
> Tor proxy and my hidden service  and my wireless access point that lurk on 
> the same Pi. 
> 
> This is not a good reason to punish my relay. Makes ZERO sense to me and to 
> who knows how many people like me whose relays are flushed down the drain by 
> the current DirAuth algorithms.
> 
> I can think of many an Iranian or Turkish or Chinese or Russian dissident who 
> could use 1.5 mbps bandwidth to communicate with the free world.

Rana,

Your relay is actually getting about as much traffic as a middle relay of that 
size should expect.

When you change the IP address, it takes a while to re-establish that traffic, 
as it should, due to the reasons I mentioned in my original email.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

Thanks Netgear Ready for the constructive approach. Here is my torrc (nickname 
redacted). There is no hidden service running on the Pi and no connections to 
the transparent proxy (its respective wifi interface is down). The Pi is doing 
nothing except the Tor relay, memory utilization 13%, CPU close to nil.

 My uplink is consistent at 1.5 mbps measured using speedtest-cli from the Pi, 
downlink is much higher. Consensus weight is 14 (!), Atlas "advertised" 
bandwidth currently 85 KB/s but sometimes reaches as high as 170 KB/s.  Actual 
traffic is practically negligible (14 MB in 6 hours). I have a Stable flag and 
am running for a month, the last 9 days with the same IP. Help will be much 
appreciated.

Rana

-
Log notice file /var/log/tor/notices.log
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsSuffixes .onion,.exit
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 172.24.1.1
DNSPort 53
DNSListenAddress 172.24.1.1
DisableDebuggerAttachment 0
RunAsDaemon 1
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServiceDir /var/lib/tor/other_hidden_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22
ORPort 9001
Nickname 
RelayBandwidthRate 250 KB  # Throttle traffic to250KB/s (2.0 Mbit/sec)
RelayBandwidthBurst 350 KB # But allow bursts up to 350KB/s (2.8 Mbit/sec)
DirPort 9030 # what port to advertise for directory connections
ExitPolicy reject *:* # no exits allowed



-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Netgear Ready
Sent: Sunday, December 04, 2016 10:44 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

Hey,

Im not sure if I'm entitled to post here, but i think my contribution might be 
useful. I am running two relays on dynamic IPs which change about very 24hours, 
my advertised bandwidth is around 700KB/s, Actually used are around 150KB/s 
which gives about 20% of the advertised bandwidth. This ratio is of course 
little bit lower than the static IP relays but by no means as severe as Rana’s. 
Maybe Rana’s configuration might have a problem and we should make a step back 
and look closer on Rana’s configuration to figure out what’s going on.

Kind regards



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

Since when is there a requirement for a relay operator to have "programming 
skills"? 

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Ralph Seichter
Sent: Sunday, December 04, 2016 8:40 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

On 04.12.16 17:54, Rana wrote:

> In short, if Tor Project does not want relays with dynamic IP, it 
> should say so and I would stop wasting my time.

What's with the entitlement issues? You are free to contribute to the Tor 
project, but if you don't have the programming skills or the wish to do so, at 
least don't complain about other peoples' work in such a hostile manner. Nobody 
here owes you anything.

-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

Please clarify what you mean by "submit a patch". 

I am not one of Tor technical contributors, nor do I presume capability of 
being one. I can only report my findings as a relay operator. Which I have 
already done here, in full detail.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Sebastian Niehaus
Sent: Sunday, December 04, 2016 7:05 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

Am 04.12.2016 um 17:54 schrieb Rana:

> In short, if Tor Project does not want relays with dynamic IP, it 
> should say so and I would stop wasting my time. Otherwise, Tor should 
> fix what's broken.

Please submit a patch.


Thanks.


Crying about what tor shold do to please you seems not very productive.


Sebastian




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Matt Traudt
Sent: Sunday, December 04, 2016 6:20 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP



On 12/04/2016 10:39 AM, Rana wrote:
>> For as little as $10.00 US there are VPS' with static ip's..
> 
> Attn: Kurt Besig
> 
> Well I kind o' like my Raspberry Pi that cost me $40 including box and power 
> supply and SD card and door to door delivery, with far more horsepower and 
> memory than needed for running Tor relay, and my free and absolutely stable 
> 1.5mbps that I want to donate to Tor courtesy of my ISP, and my transparent 
> Tor proxy and my hidden service  and my wireless access point that lurk on 
> the same Pi. 
> 
> This is not a good reason to punish my relay. Makes ZERO sense to me and to 
> who knows how many people like me whose relays are flushed down the drain by 
> the current DirAuth algorithms.
> 
> I can think of many an Iranian or Turkish or Chinese or Russian dissident who 
> could use 1.5 mbps bandwidth to communicate with the free world.
> 
> 
> 

Perhaps all that other stuff you have running on the Pi is hurting your ability 
to max out your connection.

In any case, as I mentioned on your Reddit post a week or so ago, just because 
you have X available bandwidth, doesn't mean Tor will be able to use all X. I 
have some relays on 10 Gbps links. Even if they were only 1 Gbps links, the max 
traffic I'm seeing right now is about 65 Mbps. Atlas says I'm "advertising" 
(been measured at) ~140 Mbps.

https://atlas.torproject.org/#search/x76slvferal

So I'm pushing roughly half that atlas says I could be, and I'm pushing nowhere 
near the amount my hosting provider says my links are capable of.

I've heard (but haven't verified) that clients rarely use non-Stable non-Fast 
relays. So if you are struggling to maintain those flags, then that would be 
why you're having trouble getting up to 1.5 Mbps usage.

Here is how Stable is determined according to dir-spec

https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2267

Finally, I'd like to reiterate teor

> * a changed IP usually means a changed network with different
>   characteristics,
> * if the relay IP address changes, there's no guarantee it will be 
> just as reachable or stable at the new IP,
> * stolen keys become much less valuable,
> * duplicate keys / failover strategies are discouraged.

It sounds like your IP is _too_ dynamic for best supporting the network.

Thank you for running a relay and please do not be discouraged by numbers.

Matt

__

Thank you Matt but some of your assumptions concerning my relay do not hold 
water. 

Yes, I do have a Stable flag. 

No, my hidden service and my Tor proxy and My wireless access point are NOT 
hindering the operation of my relay, since I disabled them 3 weeks ago to make 
sure they do not interfere (and they could not possibly interfere when they 
were not disabled, their bandwidth, memory and CPU consumption were practically 
zero).

No, my "advertised" (misnomer in Atlas of course, should say "measured", caused 
much confusion on my side) bandwidth is NOT a small fraction of my real 
advertised bandwdith, it is about 50% of my advertised bandwidth.

No, my actual bandwidth is not just a 2-3 of times less than that measured and 
reported in Atlas, like in your case. In my case it is 160 [HUNDRED AND SIXTY] 
times less. Here is how I calculated it: my Atlas "advertised" bandwidth is 100 
KB/s (=800 kbit/s). Every 6 hours my relay sends about 14 MB (as reported in 
heartbeats in the log). Therefore my actual average bandwidth utilization is 5 
kbit/s.

No, changed IP usually does NOT mean changed network. It usually means dynamic 
IP which has nothing to do with changes in the network or its performance, or 
stolen keys.

In short, if Tor Project does not want relays with dynamic IP, it should say so 
and I would stop wasting my time. Otherwise, Tor should fix what's broken. 
There are 7000 relays total. Do you know how many Raspberry Pis are out there? 
Many, many times more, many of them run by privacy enthusiasts with dynamic IP. 
Tor is flushing them all down the drain but STATES that it wants relays with 
dynamic IP, too (I saw it somewhere on official Tor Project pages).




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

With bandwidth rating of 14 [FOURTEEN]  after 1 month of almost uninterrupted 
presence, including last 9 days of absolutely stable performance and stable IP, 
and with Stable flag and with Fast and HSDir votes from three DirAuths? Naah, I 
do not believe this. Something is broken there and this something is not my 
relay.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Ralph Seichter
Sent: Sunday, December 04, 2016 6:15 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

On 04.12.16 16:39, Rana wrote:

> >I can think of many an Iranian or Turkish or Chinese or Russian 
> >dissident who could use 1.5 mbps bandwidth to communicate with the 
>> free world.

>So just leave your relay running, and when other relays with better 
>connectivity and a higher consensus rate are saturated, yours will start to 
>see more traffic.

>-Ralph 

With bandwidth rating of 14 [FOURTEEN]  after 1 month of almost uninterrupted 
presence, including last 9 days of absolutely stable performance and stable IP, 
and with Stable flag and with Fast and HSDir votes from three DirAuths? Naah, I 
do not believe this. 

Something is broken there and this something is certainly not my relay.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

>For as little as $10.00 US there are VPS' with static ip's..

Attn: Kurt Besig

Well I kind o' like my Raspberry Pi that cost me $40 including box and power 
supply and SD card and door to door delivery, with far more horsepower and 
memory than needed for running Tor relay, and my free and absolutely stable 
1.5mbps that I want to donate to Tor courtesy of my ISP, and my transparent Tor 
proxy and my hidden service  and my wireless access point that lurk on the same 
Pi. 

This is not a good reason to punish my relay. Makes ZERO sense to me and to who 
knows how many people like me whose relays are flushed down the drain by the 
current DirAuth algorithms.

I can think of many an Iranian or Turkish or Chinese or Russian dissident who 
could use 1.5 mbps bandwidth to communicate with the free world.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Unwarranted discrimination of relays with dynamic IP

[Rana]

I have been running a relay with dynamic IP for a month now and quite
obviously my relay is severely punished for having a dynamic IP. The IP may
change once in several days (currently running over a week with the same IP
and I just got my Stable flag back again, about 3 weeks after losing it).
The relay's throughput is a tiny fraction (less than 10%) of the actual
capacity which I programmed the torrc file to donate. The capacity I wanted
to donate is less than the uplink speed of my internet connection (the
downlink speed is higher than downlink and is thus irrelevant here).
 
I started with a consensus rating of 21, which went up to 30 and then after
a couple of IP changes collapsed to 13. It is now 14, and never went above
this again,  with the relay running ALL THE TIME stably for a month minus a
small number of restarts due to IP changes. As I said, stable IP for a week
now and a Stable flag. 
 
1.   Why is the relay with dynamic IP punished? This makes zero sense to
me. IMHO changing an IP once a week and running stably between such changes
is stable enough for all practical purposes. And since the fingerprint of
the relay does not change when the IP is changed, dirauths know that this is
the same stable node.
 
2.   The "advertised bandwidth" that I see in Atlas has absolutely
nothing to do either with the bandwidth that I advertise (it is 3-4 times
larger than what I see in Atlas) or with the actual data throughput of my
relay (it is 20 times smaller than what I see in Atlas). Can somebody
explain this?
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Outgoing Connections to middle nodes?

[Rana]

So based on Michael's reply, I now understand (I also run a middle relay) why 
when I check connections in ARM I am getting 3 sections: inbound, outbound and 
circuits. None of the inbound or outbound connections' nodes participate in the 
circuits.

For example, right now I have 9 inbound, 4 outbound and 21 circuits. Am I 
correct in assuming that the 21 circuits are IN ADDITION to the inbound and 
outbound connections, and are all circuits to rendezvous or introduction points?

I further assume that most of the connections created for the circuits are 
likely to linger for a long time, especially those to the introduction points. 
Am I right?

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Michael Armbruster
Sent: Saturday, December 03, 2016 2:10 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Outgoing Connections to middle nodes?

On 2016-12-03 at 12:56, balbea16 wrote:
> Hi There,
> I've got a quick question. I have been running a tor relay since 3 
> months. I don't have a guard flag, however many outgoing connections 
> to non exit relays  (i.e. that should be middles than). Does that mean 
> I run an entry node  (without having guard status)? How come?
> TNX Mike

Hi Mike,

you forget about hidden services IN the Tor network. Not every connection tries 
to connect to domains or services outside the Tor network.

So it could be that you are a middle relay having many outgoing connections to 
so-called rendezvous points.

Have a look at this sentence here from [1]:
"In general, the complete connection between client and hidden service consists 
of 6 relays: 3 of them were picked by the client with the third being the 
rendezvous point and the other 3 were picked by the hidden service."

Best,
Michael

[1] https://www.torproject.org/docs/hidden-services.html.en


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays