Re: [tor-relays] UbuntuCore

2017-10-29 Thread Roger Dingledine
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.

Re: [tor-relays] UbuntuCore

2017-10-29 Thread tor
> 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] UbuntuCore

2017-10-29 Thread Paul Templeton
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

[tor-relays] Relay flag set counts

2017-10-29 Thread grarpamp
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

Re: [tor-relays] "Fast" flag definition

2017-10-29 Thread Igor Mitrofanov
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 pro

Re: [tor-relays] "Fast" flag definition

2017-10-29 Thread Roger Dingledine
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? I

Re: [tor-relays] "Fast" flag definition

2017-10-29 Thread teor
> 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? I

[tor-relays] "Fast" flag definition

2017-10-29 Thread Igor Mitrofanov
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 7

Re: [tor-relays] Exit probability

2017-10-29 Thread Roger Dingledine
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, >

Re: [tor-relays] Exit probability

2017-10-29 Thread Sebastian Urbach
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

[tor-relays] Exit probability

2017-10-29 Thread 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

Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP

2017-10-29 Thread teor
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 ha

Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP

2017-10-29 Thread Toralf Förster
-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

Re: [tor-relays] sum of consensus weight of 2 relays running at the same IP

2017-10-29 Thread teor
> 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 int

[tor-relays] sum of consensus weight of 2 relays running at the same IP

2017-10-29 Thread Toralf Förster
-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 ? - -- T