[tor-relays] sum of consensus weight of 2 relays running at the same IP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I assumed that 2 Tor at the same ip address would get haöf of the consensus of the previously runnning only one Tor relay at the same hardware. But it semes, that both Tor relays get now the same value as the one before. Is this intended ? - -- Toralf PGP C4EACDDE 0076E94E -BEGIN PGP SIGNATURE- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWfW5BRccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTse3AP9waxb9fe+ECq0QyR2PkS6Tw3j1 Lc+H7UafeeuUalHJngEAg9pg1jHzZnrEir03xCQEeP9HRrtfbKCUBo/AI/40KMo= =wt5I -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP
> On 29 Oct 2017, at 22:18, Toralf Förster wrote: > > I assumed that 2 Tor at the same ip address would get haöf of the consensus > of the previously runnning only one Tor relay at the same hardware. > But it semes, that both Tor relays get now the same value as the one before. > > Is this intended ? Possibly. Are the relays CPU-limited, or bandwidth-limited? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/29/2017 01:24 PM, teor wrote: > Possibly. > > Are the relays CPU-limited, or bandwidth-limited? Not at all, neither limited by a config value nor by the hardware (1GBit/s, 200 MBit/s guaranteed, i7-3930, all non-Tor processes have "nice" in front, ids are 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA and 6EABEBF38CE7E3DF672C4DB01383606FE3EB2215) - -- Toralf PGP C4EACDDE 0076E94E -BEGIN PGP SIGNATURE- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWfXJzRccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTlykAPkBLZq5kyFnxdypwAm8CaT748Ii 5dhTaVfhcd/kGYnuWAD+IBFGuFQ8l9pGWz75Xg4J035vVcU1mJHyJNDx+sp7jxg= =0tQ3 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP
On 29 Oct 2017, at 23:30, Toralf Förster wrote: >> On 10/29/2017 01:24 PM, teor wrote: >> Possibly. >> >> Are the relays CPU-limited, or bandwidth-limited? > > Not at all, neither limited by a config value nor by the hardware (1GBit/s, > 200 MBit/s guaranteed, i7-3930, all non-Tor processes have "nice" in front, > ids are 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA and > 6EABEBF38CE7E3DF672C4DB01383606FE3EB2215) I'm sorry, this doesn't help me answer your question. Usually, a relay is limited by either the available network bandwidth, or by the speed of a single CPU core on the machine. If the first relay used all the available bandwidth, then two relays will eventually have lower consensus weight values. If the first relay used all of a single CPU core for its main thread, then the two relays will eventually have similar consensus weight values. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Exit probability
How is exit probability counted? Is it only port 80 exit tested? I exit many 1000s of ports, including 443, but not those of high risk of abuse emails and thus upsetting the ISP. So port 80 along with others are blocked. I realise no port 80 limits the use of the exit so not expecting so see a high probability of exit. But Atlas shows none. Currently of some 3000 connections 200 are exit. Tor atlas show exit probability of 0.% Gerry -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of teor Sent: 29 October 2017 12:45 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP On 29 Oct 2017, at 23:30, Toralf Förster wrote: >> On 10/29/2017 01:24 PM, teor wrote: >> Possibly. >> >> Are the relays CPU-limited, or bandwidth-limited? > > Not at all, neither limited by a config value nor by the hardware > (1GBit/s, 200 MBit/s guaranteed, i7-3930, all non-Tor processes have > "nice" in front, ids are 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA and > 6EABEBF38CE7E3DF672C4DB01383606FE3EB2215) I'm sorry, this doesn't help me answer your question. Usually, a relay is limited by either the available network bandwidth, or by the speed of a single CPU core on the machine. If the first relay used all the available bandwidth, then two relays will eventually have lower consensus weight values. If the first relay used all of a single CPU core for its main thread, then the two relays will eventually have similar consensus weight values. T ___ 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] Exit probability
Hi, Both servers do not have the Exit flag but every other flag necessary to become an Exit and Exit policies are also present. That could indicate some port trouble: "Exit" -- A router is called an 'Exit' iff it allows exits to at least one /8 address space on each of ports 80 and 443. (Up until Tor version 0.3.2, the flag was assigned if relays exit to at least two of the ports 80, 443, and 6667.) The Exit probability is 0 without the Exit flag. 200 Exit connections without the Exit flag ? Seems ylto be weird... -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --- Those who surrender freedom for security will not have, nor do they deserve, either one. --- Benjamin Franklin (1706-1790) Am 29. Oktober 2017 14:05:26 schrieb "Dr Gerard Bulger" : How is exit probability counted? Is it only port 80 exit tested? I exit many 1000s of ports, including 443, but not those of high risk of abuse emails and thus upsetting the ISP. So port 80 along with others are blocked. I realise no port 80 limits the use of the exit so not expecting so see a high probability of exit. But Atlas shows none. Currently of some 3000 connections 200 are exit. Tor atlas show exit probability of 0.% Gerry -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of teor Sent: 29 October 2017 12:45 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP On 29 Oct 2017, at 23:30, Toralf Förster wrote: On 10/29/2017 01:24 PM, teor wrote: Possibly. Are the relays CPU-limited, or bandwidth-limited? Not at all, neither limited by a config value nor by the hardware (1GBit/s, 200 MBit/s guaranteed, i7-3930, all non-Tor processes have "nice" in front, ids are 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA and 6EABEBF38CE7E3DF672C4DB01383606FE3EB2215) I'm sorry, this doesn't help me answer your question. Usually, a relay is limited by either the available network bandwidth, or by the speed of a single CPU core on the machine. If the first relay used all the available bandwidth, then two relays will eventually have lower consensus weight values. If the first relay used all of a single CPU core for its main thread, then the two relays will eventually have similar consensus weight values. T ___ 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 mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit probability
On Sun, Oct 29, 2017 at 03:20:47PM +0100, Sebastian Urbach wrote: > "Exit" -- A router is called an 'Exit' iff it allows exits to at least one > /8 address space on each of ports 80 and 443. (Up until Tor version 0.3.2, > the flag was assigned if relays exit to at least two of the ports 80, 443, > and 6667.) Right. And see also my future plans to make it just "80 and 443": https://bugs.torproject.org/23637 > The Exit probability is 0 without the Exit flag. 200 Exit connections > without the Exit flag ? Seems ylto be weird... I don't think it's that weird. You can read more about the goals of the Exit flag here: https://trac.torproject.org/projects/tor/ticket/22820#comment:3 but the simple summary here is that the Exit flag, and thus the exit probability, is about *load balancing*, so other clients can choose their paths in a way that produces globally useful choices. That is, think of an exit probability of 0% as saying "Other people should assume that I am not using any of my bandwidth for exit streams, so I am fully available for use in other circuit positions", not "there is no chance that you can exit from my relay". --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] "Fast" flag definition
Hi,
It looks like 94.7% of all Running relays have the "Fast" flag now. If
that percentage becomes 100%, the flag will become meaningless.
What were the reasons behind the current definition of "Fast", and are
those still valid? If not, should "Fast" become self-adjusting
("faster than 2 Mbps or 70% of all Guard relays, whichever is
greater")?
Thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "Fast" flag definition
> On 30 Oct 2017, at 10:21, Igor Mitrofanov wrote:
>
> Hi,
>
> It looks like 94.7% of all Running relays have the "Fast" flag now. If
> that percentage becomes 100%, the flag will become meaningless.
> What were the reasons behind the current definition of "Fast", and are
> those still valid? If not, should "Fast" become self-adjusting
> ("faster than 2 Mbps or 70% of all Guard relays, whichever is
> greater")?
It is self-adjusting, and we expect at least 87.5% of relays to have it:
"Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in
the top 7/8ths for known active routers or at least 100KB/s.
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2408
But maybe we could increase the threshold.
Feel free to open the ticket at:
https://trac.torproject.org/
--
Tim / teor
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "Fast" flag definition
On Sun, Oct 29, 2017 at 04:21:10PM -0700, Igor Mitrofanov wrote:
> It looks like 94.7% of all Running relays have the "Fast" flag now. If
> that percentage becomes 100%, the flag will become meaningless.
> What were the reasons behind the current definition of "Fast", and are
> those still valid? If not, should "Fast" become self-adjusting
> ("faster than 2 Mbps or 70% of all Guard relays, whichever is
> greater")?
The goal of the Fast flag is to have some minimum threshold for whether
a relay is useful at all.
It actually is self-adjusting, in that it gets assigned to the top 7/8ths
of the relays. But *also* it gets assigned to any relay that meets some
minimum bandwidth threshold:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2408
The "give it to them anyway if they're above the threshold" is a security
defense, else some jerk could sign up a whole lot of crummy relays,
driving other legitimate relays out of the network, thus making Sybil
attacks more effective.
And the threshold is currently quite low -- 100KBytes/s.
(It's actually more complicated than that, because some directory
authorities assign it based on their own measurements ("I must be voting
a consensus weight of at least 100 for this relay"), and others assign
it based on the relay's self-reported number ("The relay must be claiming
at least 100KBytes/s of capacity").)
So think of Fast more as "worth using at all", where if you don't have
the flag, you don't have a chance of being chosen, and if you do, then
the consensus weights kick in to shift traffic towards bigger relays.
--Roger
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "Fast" flag definition
Thanks Tim and Roger.
I filed https://trac.torproject.org/projects/tor/ticket/24046.
(Not looking for any immediate fixes, just making sure those "Fast" 1
KB/s relays that you can see on blutmagie.de and the 100 KB/s
threshold are not at odds with whatever minimal user experience Tor
wants to provide).
On Sun, Oct 29, 2017 at 5:47 PM, Roger Dingledine wrote:
> On Sun, Oct 29, 2017 at 04:21:10PM -0700, Igor Mitrofanov wrote:
>> It looks like 94.7% of all Running relays have the "Fast" flag now. If
>> that percentage becomes 100%, the flag will become meaningless.
>> What were the reasons behind the current definition of "Fast", and are
>> those still valid? If not, should "Fast" become self-adjusting
>> ("faster than 2 Mbps or 70% of all Guard relays, whichever is
>> greater")?
>
> The goal of the Fast flag is to have some minimum threshold for whether
> a relay is useful at all.
>
> It actually is self-adjusting, in that it gets assigned to the top 7/8ths
> of the relays. But *also* it gets assigned to any relay that meets some
> minimum bandwidth threshold:
> https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2408
>
> The "give it to them anyway if they're above the threshold" is a security
> defense, else some jerk could sign up a whole lot of crummy relays,
> driving other legitimate relays out of the network, thus making Sybil
> attacks more effective.
>
> And the threshold is currently quite low -- 100KBytes/s.
>
> (It's actually more complicated than that, because some directory
> authorities assign it based on their own measurements ("I must be voting
> a consensus weight of at least 100 for this relay"), and others assign
> it based on the relay's self-reported number ("The relay must be claiming
> at least 100KBytes/s of capacity").)
>
> So think of Fast more as "worth using at all", where if you don't have
> the flag, you don't have a chance of being chosen, and if you do, then
> the consensus weights kick in to shift traffic towards bigger relays.
>
> --Roger
>
> ___
> 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] Relay flag set counts
1 s Authority Fast HSDir Running Stable V2Dir Valid 2 s Authority Fast Running Stable V2Dir Valid 7 s Authority Running Stable V2Dir Valid 270 s Exit Fast Guard HSDir Running Stable V2Dir Valid 58 s Exit Fast Guard Running Stable V2Dir Valid 25 s Exit Fast Guard Running Stable Valid 168 s Exit Fast HSDir Running Stable V2Dir Valid 71 s Exit Fast Running Stable V2Dir Valid 45 s Exit Fast Running Stable Valid 149 s Exit Fast Running V2Dir Valid 15 s Exit Fast Running Valid 7 s Exit Running Stable V2Dir Valid 10 s Exit Running Stable Valid 3 s Exit Running V2Dir Valid 2 s Exit Running Valid 1293 s Fast Guard HSDir Running Stable V2Dir Valid 311 s Fast Guard Running Stable V2Dir Valid 167 s Fast Guard Running Stable Valid 1721 s Fast HSDir Running Stable V2Dir Valid 513 s Fast Running Stable V2Dir Valid 469 s Fast Running Stable Valid 754 s Fast Running V2Dir Valid 200 s Fast Running Valid 96 s Running Stable V2Dir Valid 41 s Running Stable Valid 95 s Running V2Dir Valid 27 s Running Valid ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] UbuntuCore
These nodes are popping up everywhere - is this some sort of malware being deployed on systems around the globe? Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] UbuntuCore
> These nodes are popping up everywhere - is this some sort of malware being > deployed on systems around the globe? Interesting. It does look like malware to me. - all running Tor 0.3.1.7 on Linux - diverse AS / IP allocation, mostly looks like ISP end-subscriber - same exit policy (reject *:*)___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] UbuntuCore
On Mon, Oct 30, 2017 at 03:23:07AM +, Paul Templeton wrote: > These nodes are popping up everywhere - is this some sort of malware being > deployed on systems around the globe? It is an Ubuntu snap package. See this thread: https://lists.torproject.org/pipermail/tor-relays/2016-August/010046.html --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
