Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

2020-02-02 Thread teor
Hi John,

>> On 2 Feb 2020, at 14:15, John Ricketts  wrote:
>> 
>> I have been watching the consensus weight and bandwidth of all of my 50 exit 
>> nodes drop consistently over the past few months. I have not made any 
>> hardware changes in my data center and actual
>> customers have not complained about any performance issues.
>> 
>> Operating systems and Tor version are up to date. I'm dedicating a 
>> significant portion of bandwidth to these nodes - 10gbit/sec.
>> 
>> Am I having issues with the bandwidth authorities?
>> 
>> I'm growing frustrated with my performance to resources ratio, I should be 
>> doing far better than this.
>> 
>> Please throw ideas at me - open to any ideas.
> 
> On Feb 1, 2020, at 20:05, "starlight.201...@binnacle.cx" 
>  wrote:
> 
> The rating shift experienced by your relays and many others is likely a 
> consequence of the gradual phase-in of the SBWS scanner implementation in 
> place of TorFlow.  I for one find SWBS unimpressive.

There are known bugs in both bandwidth authority implementations,
sbws and torflow. Here's a list of the critical sbws bugs:
https://trac.torproject.org/projects/tor/query?status=!closed=~sbws-majority-blocker

We're working on getting some funding to fix these bugs in sbws.

(Torflow is very old and hard to install, most of its dependencies are
unsupported. So we aren't tracking torflow bugs in detail any more.)

I don't think we've added any sbws instances for a few months. And I
haven't seen any specific evidence that sbws (or torflow) is
responsible for these issues.

If you give us a timeframe, we might be able to help more.

It's also possible that there are more exits in the Tor network, or
that the routing between the bandwidth authorities and your network
has become slower.

There are some other common explanations for slow relays, listed on
this wiki page:
https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow

You might find some of the tips on that page helpful.

Also, if you can find some authorities that are giving your relays
low measurements, we might be able to find out why.

You can see a copy of all the bandwidth authority measurements here:
https://consensus-health.torproject.org/consensus-health.html

T

--
teor
--



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] tor version 0.4.0.x reaches end-of-life on 2020-02-02

2020-02-02 Thread teor
Hi,

> On 2 Feb 2020, at 23:55, nusenu  wrote:
> 
> Signed PGP part
> Toralf Förster:> I do wonder if recent Tor clients do already prefer to not 
> choose EOL relays?
> 
> Version information (or the recommended version list) is not part of the path 
> selection algorithm
> of tor clients.

But we do use the recommended version list to select fallback
directory mirrors. So when we next rebuild the fallback list
(later in 2020), all relays on 0.2.9 and 0.4.0 will be removed.

Clients may use relay protocol versions to choose paths, when we
add new features that they want to use. But that's a long way away.

All supported Tor versions (and 0.4.0) support the most recent tor
Relay protocols. So clients don't have any reason to choose between
relays based on versions right now.

In Tor 0.4.4, we'll introduce a new Relay protocol for IPv6 extends,
to support relay IPv6 reachability checks. Clients will ignore it,
until they start doing IPv6 extends. (We think we need more IPv6
relays, before clients can safely use IPv6 extends. In the meantime,
clients just do IPv4 extends, and every relay has IPv4.)

T

--
teor
--



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] tor version 0.4.0.x reaches end-of-life on 2020-02-02

2020-02-02 Thread nusenu
Toralf Förster:> I do wonder if recent Tor clients do already prefer to not 
choose EOL relays?

Version information (or the recommended version list) is not part of the path 
selection algorithm
of tor clients.


-- 
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] tor version 0.4.0.x reaches end-of-life on 2020-02-02

2020-02-02 Thread Toralf Förster
On 2/2/20 1:49 PM, nusenu wrote:
> Currently over 10% of the network is running on end-of-life tor releases, 
> this is bad.

I do wonder if recent Tor clients do already prefer to not choose EOL relays?

-- 
Toralf



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] tor version 0.4.0.x reaches end-of-life on 2020-02-02

2020-02-02 Thread nusenu
The table bellow should help you find out whether you run an EOL version of tor 
(if you set a contactInfo string).

Currently over 10% of the network is running on end-of-life tor releases, this 
is bad.
https://nusenu.github.io/OrNetStats/#end-of-life-relays-share

data as of: 2020-02-02 12:00 UTC

++--+-+-+
| cw | contact  | 
#relays | used_versions   |
++--+-+-+
| 280300 | Thomas Steen Rasmussen / Tykling  (PGP: 0 |   
3 | 0.4.0.5 |
| 254000 | Gijs Rijnders (tor AT ip-eend DOT nl)|   
3 | 0.4.0.5 |
| 116292 | Random Person |   
6 | 0.2.9.10,0.4.0.5|
| 107530 | foore...@hotmail.com |  
10 | 0.2.9.17|
| 104000 | DFRI  - 1Muz37TfXVBiJKRJkAqTNo7MnEZN8hhm |   
3 | 0.4.0.5 |
|  97200 | torpids AT yahoo dot com - 1JYHfzVFVD7n2Sezz3DEHDFgGYjQWpDjq |   
4 | 0.4.0.1-alpha,0.4.0.3-alpha,0.4.0.5 |
|  97000 |  |   
1 | 0.2.9.16|
|  83400 | t...@govanify.com |  
 1 | 0.4.0.5 |
|  67200 | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHz |   
5 | 0.4.0.5 |
|  66500 | KeFF NOC|   
1 | 0.4.0.5 |
|  63000 | ab...@maytownsend.is < abuse AT maytownsend dot is>  |   
1 | 0.4.0.5 |
|  61000 | s...@hijnn.net   |   
1 | 0.4.0.5 |
|  61000 | Tor Reactor  <0d0[AT]protonmail.com> | u42omsvzmh7momdk.onio |   
1 | 0.4.0.5 |
|  59000 | t...@texthtml.net |  
 1 | 0.4.0.5 |
|  56000 |  jannisd...@eclipso.eu   |   
1 | 0.4.0.5 |
|  51370 | t...@example.org |   
4 | 0.4.0.5 |
|  44000 | fredreic(at)tutanota(dot)com |   
1 | 0.4.0.6 |
|  42000 | mail[at]nozel[.]org  |   
2 | 0.4.0.5 |
|  38600 | OMP o...@cock.li  |  
 1 | 0.2.9.16|
|  32000 | Network Operations  |  
 1 | 0.4.0.2-alpha   |
|  31000 | dev.n...@kryptonit.org - 1AjBZw8ExjkWgh7Y5s9mLX4UXHadzPfKQu  |   
1 | 0.4.0.5 |
|  29400 | 5...@gmx.ch [tor-relay.co]|  
 1 | 0.4.0.5 |
|  29050 | Dave Null |   
4 | 0.2.9.17|
|  29000 | 1Jwjq2AGPua8urdfZXtSbEQCKBQWF34qew  ronstorabuse[a]protonmai |   
1 | 0.4.0.5 |
|  29000 | t...@moletrix.be  |  
 1 | 0.4.0.5 |
|  29000 | william.san...@hotmail.co.uk |   
1 | 0.4.0.5 |
|  28000 | email: torc...@gmx.net   |   
1 | 0.4.0.6 |
|  27900 | ne...@pm.me  |   
1 | 0.2.9.16|
|  25400 | tor-ato...@protonmail.com|   
1 | 0.4.0.5 |
|  25000 | jjack...@laposte.net |   
1 | 0.2.9.16|
|  24100 | tor atgoeshere nerdpol dotgoeshere org   |   
1 | 0.2.9.17|
|  24000 | t...@ueno.red |  
 1 | 0.4.0.5 |
|  23800 | tor+torro...@tzu.io  |   
1 | 0.4.0.5 |
|  23300 | jorge  |   
1 | 0.4.0.6 |
|  23000 | 4096R/5819E33F Zhongfu Li |   
1 | 0.4.0.5 |
|  22100 | pho...@protonmail.com|   
1 | 0.4.0.5 |
|  22000 | not-wanted [at] unknown [dot] com|   
1