[tor-relays] Testing Golang relay implementation

[Michael McLoughlin]

All,

I am working on a pure Golang relay implementation.

https://github.com/mmcloughlin/pearl/

I have thus far been testing locally with chutney (
https://gitweb.torproject.org/chutney.git). The project is not complete by
any stretch, but I believe I am close to the point where it can handle Tor
network traffic. I expect I can learn *a lot* by running against real
traffic rather than my sandboxed environment.

I wanted to get in touch with the community before going live. Any advice
gratefully received.

The implementation identifies itself clearly in the server descriptor, both
in the "platform" and "contact" items. If people notice any problems with
the relay specifically they will be able to contact me.

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

Re: [tor-relays] decrease in traffic

[Trey Nolen]

On 10/23/2017 6:12 PM, teor wrote:

On 24 Oct 2017, at 09:08, s7r  wrote:

it looks like your relay has a measured by authority 'bastet' of
355. That is not a big value. The other authorities measured this:

278;
355;
367;
803;

So it looks like the speed was pretty much the same for the measurements
performed on your relay by different servers on different networks. If
you say you are sure there is nothing automated (at either OS level,
hypervisor level, local router/network level or something upstream) that
could throttle this in case of continuous high usage

Your AS shows up as BellSouth.net, which redirects to AT
Have you asked them if they're throttling you?

(Or do you work for BellSouth?)


there's not much
you can do other than waiting some time to see the next speed measurements.

You can check the warning and notice level Tor logs to see the amount
of traffic Tor thinks it is handling.

You can also tap or mouse over the bandwidth in Atlas, and it will show
you what's limiting your relay - in this case, it appears to be the consensus
weight. (The observed maximum bandwidth is 2.44 MBps, and the rate and
burst are 5 and 10 MBps.)

Unfortunately, sometimes relays get stuck in a low measurement category.
We're working on a test environment, so we can start fixing issues like this.

In the meantime, you can try the following things:
* restart the relay
* change the IP address
* delete all the relay keys and start again

You might want to wait a week or so after trying each step.
Please let us know if one of these things works, it will help us diagnose
the issue.



I've already restarted the relay (been about 5-6 days).  It was doing 
this before the restart although it continues to decline. I'll delete 
the whole VPS and create a new one.
LOL...guess I'll be starting new on my t-shirt authorization (but that 
is another thread...).



Trey Nolen


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

Re: [tor-relays] Decline in relays

[nusenu]

(don't take this information as granted this was a quick 'n dirty thing)

David Goulet:
> Since July 2017

It appears to have started earlier than July if you graph metrics' csv
file for better granularity. Maybe somewhere in mid May 2017 (maybe when
tor 0.2.9.x -> 0.3.0 started to spread? -> correlate it with the relays
by version graph)

> which relays went offline

I compared two sets of relays (identified by FP):

1) all relays included in onionoo data from 2017-05-07 00:00
(that means also non-running relays that were running at some point
during the week before that timestamp)
This set has 7334 _running_ relays (8681 in total)

2) all relays - including non-running relays - included in onionoo data
from 2017-10-23 21:00 that were added to the tor network **before**
2017-05-07.
This set contains 5151 relays in total.

I'm afraid the results are not very useful due to the apparently high
churn rate. 3885 relays that were in (1) are NOT in (2).


Disappeared relays by version
(version as seen on 2017-05-07 this is NOT necessarily the same version
they did run when they were last seen):
+---+--+
| tor_version   | relays   |
+---+--+
| 0.2.9.10  | 1161 |
| 0.2.5.12  |  576 |
| 0.2.7.6   |  511 |
| 0.2.9.9   |  291 |
| 0.2.4.27  |  251 |
| 0.3.0.6   |  241 |
| 0.2.4.23  |  158 |
| 0.2.8.9   |  129 |
| 0.2.6.10  |   95 |
| 0.3.0.5-rc|   82 |
| 0.2.9.8   |   64 |
| 0.2.8.12  |   58 |
| 0.2.8.11  |   41 |
| 0.2.8.8   |   39 |
| 0.2.8.7   |   30 |
| 0.2.4.22  |   22 |
| 0.3.0.4-rc|   14 |
| 0.3.1.0-alpha-dev |   10 |
| 0.2.4.20  |9 |
| 0.2.8.10  |9 |
| 0.2.5.10  |9 |
| 0.3.0.3-alpha |8 |
| 0.2.8.6   |7 |
| 0.2.6.9   |6 |
| 0.2.7.6-dev   |5 |
| 0.2.7.5   |5 |
| 0.3.0.2-alpha |5 |
[...]

(retrieving the actually last seen version is feasible but requires
processing [much] more data)

Disappeared relays by flags
-> we loose guards, not exits
(matches somewhat relays by flag graphs on metrics)
Flags appear in this order:
stable,fast,guard,exit,hsdir
(0=not set, 1=set)
++--+
| flags  | relays   |
++--+
| 11001  |  775 |
| 11101  |  609 |
| 0  |  582 |
| 01000  |  561 |
| 11000  |  453 |
| 1  |  259 |
| 11100  |  196 |
| 1  |  131 |
| 01010  |   91 |
[...]


Disappeared relays by OS (this matches graphs on metrics):
-> we loose Linux boxes, others are static
+--++
| OS   | relays |
+--++
| Linux|   3434 |
| Windows 8|119 |
| Windows 7|111 |
| FreeBSD  |108 |
| OpenBSD  | 58 |
| Windows XP   | 22 |
| Windows 8 [server]   | 10 |
[...]







-- 
https://mastodon.social/@nusenu
twitter: @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] decrease in traffic

[teor]

> On 24 Oct 2017, at 09:08, s7r  wrote:
> 
> it looks like your relay has a measured by authority 'bastet' of
> 355. That is not a big value. The other authorities measured this:
> 
> 278;
> 355;
> 367;
> 803;
> 
> So it looks like the speed was pretty much the same for the measurements
> performed on your relay by different servers on different networks. If
> you say you are sure there is nothing automated (at either OS level,
> hypervisor level, local router/network level or something upstream) that
> could throttle this in case of continuous high usage

Your AS shows up as BellSouth.net, which redirects to AT
Have you asked them if they're throttling you?

(Or do you work for BellSouth?)

> there's not much
> you can do other than waiting some time to see the next speed measurements.

You can check the warning and notice level Tor logs to see the amount
of traffic Tor thinks it is handling.

You can also tap or mouse over the bandwidth in Atlas, and it will show
you what's limiting your relay - in this case, it appears to be the consensus
weight. (The observed maximum bandwidth is 2.44 MBps, and the rate and
burst are 5 and 10 MBps.)

Unfortunately, sometimes relays get stuck in a low measurement category.
We're working on a test environment, so we can start fixing issues like this.

In the meantime, you can try the following things:
* restart the relay
* change the IP address
* delete all the relay keys and start again

You might want to wait a week or so after trying each step.
Please let us know if one of these things works, it will help us diagnose
the issue.

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

Re: [tor-relays] decrease in traffic

[s7r]

Trey Nolen wrote:
> 
>> First of all, thanks for running a relay.
>>
>> Based on my experience, what usually happens is that the provider of
>> your VPS observed during a period of time you used more than N mbps
>> constantly and all the time, so they capped your VPS at some KB/s limit.
>> There are performance monitoring scripts that could do this
>> automatically. A virtual private server shares the network card of the
>> host with the other VPSes on that host, so almost all providers do not
>> allow you to use it all by yourself all the time for long periods. You
>> can open a ticket upstream and they will confirm if this is the case or not.
>>
>> Nothing you can do about this unfortunately, most providers do this,
>> even the ones they say they don't do it :) Only thing you can do is get
>> a dedicated server with guaranteed bandwidth, or try to convince them to
>> at least lift your the limitation for your VPS to 1mbps.
>>
>>
> 
> 
> In this case, this is not going on as we *are* the provider.   I'm a
> sysadmin on the network and I'm one of the guys that would be in charge
> of limiting any machines which violated any rules.  :-)
> 
> 
> Trey Nolen

Oh, OK. Glad to see not everybody who rents virtual private servers also
caps their bandwidth. It happened to me so many times that I could even
bet that this was the issue here, but looks like it's not.

Since atlas is down, I have looked at the votes here:
https://consensus-health.torproject.org/consensus-health.html

and it looks like your relay has a measured by authority 'bastet' of
355. That is not a big value. The other authorities measured this:

278;
355;
367;
803;

So it looks like the speed was pretty much the same for the measurements
performed on your relay by different servers on different networks. If
you say you are sure there is nothing automated (at either OS level,
hypervisor level, local router/network level or something upstream) that
could throttle this in case of continuous high usage, there's not much
you can do other than waiting some time to see the next speed measurements.



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] decrease in traffic

[Trey Nolen]

  
  
No, not yet.  I was planning on setting up Atlas but haven't had a
chance.  This was a little test server we had spun up for various
projects and we decided to just run a node on it.   However, we plan
on keeping it going now, if we can get it running so that it
actually does some real work.




On 10/23/2017 04:42 PM, Stephane
  Thevenot wrote:


  
  I'm not trhotling VPS when renting them :) for real !!
   
  BTW is the atlas webserver running ? database backend problem
?   
   
  https://atlas.torproject.org/#search/208.94.110.37
   
   
  Le 2017-10-23 17:34, s7r a écrit :
  
Hi,
  
  Trey Nolen wrote:
  I'm new to running a Tor relay
and started one about a month ago.   I've
got 50 Mbps dedicated to it and at first it climbed in
traffic pretty
steadily until it got to around 25-30 Mbps being used.  
Since then, it
has declined steadily and is down to about 350 KBps now
(yes, I'm
keeping the units straight).

My node is a single core VPS running 3.2GHz and with 1GB
RAM. 
Currently, top shows tor as using about 15% of the memory. 
When it was
churning out at the maximum rate it got to, the CPU was
pretty
hammered.  I was considering allocating another core, but
there is no
need anymore as it is hovering around 7% usage.  

The server is running on Ubuntu 16.04.3 and I'm running
0.3.1.7 tor.


Am I doing something wrong to result in the decrease in
traffic?  Any
advice is appreciated.


Trey Nolen
  
  First of all, thanks for running a relay.
  
  Based on my experience, what usually happens is that the
  provider of
  your VPS observed during a period of time you used more than N
  mbps
  constantly and all the time, so they capped your VPS at some
  KB/s limit.
  There are performance monitoring scripts that could do this
  automatically. A virtual private server shares the network
  card of the
  host with the other VPSes on that host, so almost all
  providers do not
  allow you to use it all by yourself all the time for long
  periods. You
  can open a ticket upstream and they will confirm if this is
  the case or not.
  
  Nothing you can do about this unfortunately, most providers do
  this,
  even the ones they say they don't do it :) Only thing you can
  do is get
  a dedicated server with guaranteed bandwidth, or try to
  convince them to
  at least lift your the limitation for your VPS to 1mbps.


___
  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] onionoo issue (was: decrease in traffic)

[nusenu]

Stephane Thevenot:
> BTW is the atlas webserver running ? database backend problem ?

onionoo (atlas backend) has currently some issues, the maintainer and
admins are looking into it
https://trac.torproject.org/projects/tor/ticket/23929


-- 
https://mastodon.social/@nusenu
twitter: @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] decrease in traffic

[Trey Nolen]

On 10/23/2017 04:36 PM, nusenu wrote:
>
> Trey Nolen:
>> I'm new to running a Tor relay and started one about a month ago.   I've
>> got 50 Mbps dedicated to it and at first it climbed in traffic pretty
>> steadily until it got to around 25-30 Mbps being used.   Since then, it
>> has declined steadily and is down to about 350 KBps now (yes, I'm
>> keeping the units straight).
>>
>> My node is a single core VPS running 3.2GHz and with 1GB RAM. 
>> Currently, top shows tor as using about 15% of the memory.  When it was
>> churning out at the maximum rate it got to, the CPU was pretty
>> hammered.  I was considering allocating another core, but there is no
>> need anymore as it is hovering around 7% usage.  
>>
>> The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
>>
>>
>> Am I doing something wrong to result in the decrease in traffic?  Any
>> advice is appreciated.
> It is always good to include an atlas URL or fingerprint / IP to your
> relay when asking for help about a specific relay
>
> https://atlas.torproject.org/#details/2721B60067A1EF1DE7926BAADDCAD490AB5CAE36
>
>

Thanks for the advice.  For this particular one, the fingerprint is 2721
B600 67A1 EF1D E792 6BAA DDCA D490 AB5C AE36


Trey Nolen


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

Re: [tor-relays] decrease in traffic

[Stephane Thevenot]

I'm not trhotling VPS when renting them :) for real !! 

BTW is the atlas webserver running ? database backend problem ?

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

Le 2017-10-23 17:34, s7r a écrit :

> Hi,
> 
> Trey Nolen wrote: 
> 
>> I'm new to running a Tor relay and started one about a month ago.   I've
>> got 50 Mbps dedicated to it and at first it climbed in traffic pretty
>> steadily until it got to around 25-30 Mbps being used.   Since then, it
>> has declined steadily and is down to about 350 KBps now (yes, I'm
>> keeping the units straight).
>> 
>> My node is a single core VPS running 3.2GHz and with 1GB RAM. 
>> Currently, top shows tor as using about 15% of the memory.  When it was
>> churning out at the maximum rate it got to, the CPU was pretty
>> hammered.  I was considering allocating another core, but there is no
>> need anymore as it is hovering around 7% usage.  
>> 
>> The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
>> 
>> Am I doing something wrong to result in the decrease in traffic?  Any
>> advice is appreciated.
>> 
>> Trey Nolen
> 
> First of all, thanks for running a relay.
> 
> Based on my experience, what usually happens is that the provider of
> your VPS observed during a period of time you used more than N mbps
> constantly and all the time, so they capped your VPS at some KB/s limit.
> There are performance monitoring scripts that could do this
> automatically. A virtual private server shares the network card of the
> host with the other VPSes on that host, so almost all providers do not
> allow you to use it all by yourself all the time for long periods. You
> can open a ticket upstream and they will confirm if this is the case or not.
> 
> Nothing you can do about this unfortunately, most providers do this,
> even the ones they say they don't do it :) Only thing you can do is get
> a dedicated server with guaranteed bandwidth, or try to convince them to
> at least lift your the limitation for your VPS to 1mbps.
> 
> ___
> 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] decrease in traffic

[Trey Nolen]

> First of all, thanks for running a relay.
>
> Based on my experience, what usually happens is that the provider of
> your VPS observed during a period of time you used more than N mbps
> constantly and all the time, so they capped your VPS at some KB/s limit.
> There are performance monitoring scripts that could do this
> automatically. A virtual private server shares the network card of the
> host with the other VPSes on that host, so almost all providers do not
> allow you to use it all by yourself all the time for long periods. You
> can open a ticket upstream and they will confirm if this is the case or not.
>
> Nothing you can do about this unfortunately, most providers do this,
> even the ones they say they don't do it :) Only thing you can do is get
> a dedicated server with guaranteed bandwidth, or try to convince them to
> at least lift your the limitation for your VPS to 1mbps.
>
>


In this case, this is not going on as we *are* the provider.   I'm a
sysadmin on the network and I'm one of the guys that would be in charge
of limiting any machines which violated any rules.  :-)


Trey Nolen


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

Re: [tor-relays] decrease in traffic

[s7r]

Hi,

Trey Nolen wrote:
> I'm new to running a Tor relay and started one about a month ago.   I've
> got 50 Mbps dedicated to it and at first it climbed in traffic pretty
> steadily until it got to around 25-30 Mbps being used.   Since then, it
> has declined steadily and is down to about 350 KBps now (yes, I'm
> keeping the units straight).
> 
> My node is a single core VPS running 3.2GHz and with 1GB RAM. 
> Currently, top shows tor as using about 15% of the memory.  When it was
> churning out at the maximum rate it got to, the CPU was pretty
> hammered.  I was considering allocating another core, but there is no
> need anymore as it is hovering around 7% usage.  
> 
> The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
> 
> 
> Am I doing something wrong to result in the decrease in traffic?  Any
> advice is appreciated.
> 
> 
> Trey Nolen

First of all, thanks for running a relay.

Based on my experience, what usually happens is that the provider of
your VPS observed during a period of time you used more than N mbps
constantly and all the time, so they capped your VPS at some KB/s limit.
There are performance monitoring scripts that could do this
automatically. A virtual private server shares the network card of the
host with the other VPSes on that host, so almost all providers do not
allow you to use it all by yourself all the time for long periods. You
can open a ticket upstream and they will confirm if this is the case or not.

Nothing you can do about this unfortunately, most providers do this,
even the ones they say they don't do it :) Only thing you can do is get
a dedicated server with guaranteed bandwidth, or try to convince them to
at least lift your the limitation for your VPS to 1mbps.



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] decrease in traffic

[nusenu]

Trey Nolen:
> I'm new to running a Tor relay and started one about a month ago.   I've
> got 50 Mbps dedicated to it and at first it climbed in traffic pretty
> steadily until it got to around 25-30 Mbps being used.   Since then, it
> has declined steadily and is down to about 350 KBps now (yes, I'm
> keeping the units straight).
> 
> My node is a single core VPS running 3.2GHz and with 1GB RAM. 
> Currently, top shows tor as using about 15% of the memory.  When it was
> churning out at the maximum rate it got to, the CPU was pretty
> hammered.  I was considering allocating another core, but there is no
> need anymore as it is hovering around 7% usage.  
> 
> The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
> 
> 
> Am I doing something wrong to result in the decrease in traffic?  Any
> advice is appreciated.

It is always good to include an atlas URL or fingerprint / IP to your
relay when asking for help about a specific relay

https://atlas.torproject.org/#details/2721B60067A1EF1DE7926BAADDCAD490AB5CAE36

-- 
https://mastodon.social/@nusenu
twitter: @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

[tor-relays] decrease in traffic

[Trey Nolen]

I'm new to running a Tor relay and started one about a month ago.   I've
got 50 Mbps dedicated to it and at first it climbed in traffic pretty
steadily until it got to around 25-30 Mbps being used.   Since then, it
has declined steadily and is down to about 350 KBps now (yes, I'm
keeping the units straight).

My node is a single core VPS running 3.2GHz and with 1GB RAM. 
Currently, top shows tor as using about 15% of the memory.  When it was
churning out at the maximum rate it got to, the CPU was pretty
hammered.  I was considering allocating another core, but there is no
need anymore as it is hovering around 7% usage.  

The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.


Am I doing something wrong to result in the decrease in traffic?  Any
advice is appreciated.


Trey Nolen


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

Re: [tor-relays] Decline in relays

[David Goulet]

On 23 Oct (22:49:55), rasptor 4273 wrote:
> My relay has gone off the consensus.
> Fingerprint: E7FFF8C3D5736AB87215C5DB05620103033E69C3

Interesting. And it is still running as of now without any problems? Can you
give me the IP/ORPORT tuple?

You think you can add this to your torrc and then HUP your relay (very
importatnt to NOT restart it).

Log info file 

And then after a some hours (maybe a day), we'll be looking for "Decided to
publish new relay descriptor".

If it appears, we know that your relay keeps uploading to the directory
authorities so thus chances are that there is a problem on the dirauth side
not finding you reachable.

Thanks!
David

> Alias: rasptor4273
> Am running Tor 0.2.5.14 on Debian, Raspberry Pi 2B. I upgraded to that
> version on September 3rd.
> 
> I grepped through these:
> https://collector.torproject.org/archive/relay-descriptors/consensuses/ and
> the latest entry I found for my alias is in the file
> ./17/2017-09-17-13-00-00-consensus.
> 
> Not sure what other information I can provide. Do let me know if I can do
> anything else to help troubleshoot.
> 
> Best,
> Joep
> 
> On Mon, Oct 23, 2017 at 9:14 PM, George  wrote:
> 
> > David Goulet:
> > > Hello everyone!
> > >
> > > Since July 2017, there has been a steady decline in relays from ~7k to
> > now
> > > ~6.5k. This is a bit unusual that is we don't see often such a steady
> > behavior
> > > of relays going offline (at least that I can remember...).
> > >
> > > It could certainly be something normal here. However, we shouldn't rule
> > out a
> > > bug in tor as well. The steadyness of the decline makes me a bit more
> > worried
> > > than usual.
> > >
> > > You can see the decline has started around July 2017:
> > >
> > > https://metrics.torproject.org/networksize.html?start=
> > 2017-06-01=2017-10-23
> > >
> > > What happened around July in terms of tor release:
> > >
> > > 2017-06-08 09:35:17 -0400 802d30d9b7  (tag: tor-0.3.0.8)
> > > 2017-06-08 09:47:44 -0400 e14006a545  (tag: tor-0.2.5.14)
> > > 2017-06-08 09:47:58 -0400 aa89500225  (tag: tor-0.2.9.11)
> > > 2017-06-08 09:55:28 -0400 f833164576  (tag: tor-0.2.4.29)
> > > 2017-06-08 09:55:58 -0400 21a9e5371d  (tag: tor-0.2.6.12)
> > > 2017-06-08 09:56:15 -0400 3db01d3b56  (tag: tor-0.2.7.8)
> > > 2017-06-08 09:58:36 -0400 64ac28ef5d  (tag: tor-0.2.8.14)
> > > 2017-06-08 10:15:41 -0400 dc47d936d4  (tag: tor-0.3.1.3-alpha)
> > > ...
> > > 2017-06-29 16:56:13 -0400 fab91a290d  (tag: tor-0.3.1.4-alpha)
> > > 2017-06-29 17:03:23 -0400 22b3bf094e  (tag: tor-0.3.0.9)
> > > ...
> > > 2017-08-01 11:33:36 -0400 83389502ee  (tag: tor-0.3.1.5-alpha)
> > > 2017-08-02 11:50:57 -0400 c33db290a9  (tag: tor-0.3.0.10)
> > >
> > > Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life.
> > >
> > > That being said, I don't have an easy way to list which relays went
> > offline
> > > during the decline (since July basically) to see if a common pattern
> > emerges.
> > >
> > > So few things. First, if anyone on this list noticed that their relay
> > went off
> > > the consensus while still having tor running, it is a good time to
> > inform this
> > > thread :).
> > >
> > > Second, anyone could have an idea of what possibly is going on that is
> > have
> > > one or more theories. Even better, if you have some tooling to try to
> > list
> > > which relays went offline, that would be _awesome_.
> > >
> > > Third, knowing what was the state of packaging in
> > Debian/Redhat/Ubuntu/...
> > > around July could be useful. What if a package in distro X is broken and
> > the
> > > update have been killing the relays? Or something like that...
> > >
> > > Last, looking at the dirauth would be a good idea. Basically, when did
> > the
> > > majority switched to 030 and then 031. Starting in July, what was the
> > state of
> > > the dirauth version?
> > >
> > > Any help is very welcome! Again, this decline could be from natural
> > cause but
> > > for now I just don't want to rule out an issue in tor or packaging.
> >
> > (Replying to OP since it went OT)
> >
> > As some of you know, TDP did a little suite of shell scripts based on
> > OONI data to look at diversity statistics:
> >
> > https://torbsd.github.io/oostats.html
> >
> > With the source here for further tinkering:
> >
> > https://github.com/torbsd/tdp-onion-stats/
> >
> > Maybe something we could look at is "exception reports", which in some
> > industries means regular reports that look at anomalies or "exceptions"
> > which display out-of-the-ordinary statistics, generally prompting some
> > sort of action.
> >
> > In other words, daily reports would be run on, say, bw consensus by
> > country, and if there was some statistically significant change over N
> > periods of time, it would be noted. Or if a particular OS drops or
> > jumps. Or if a particular AS jumps or declines for relays, bridges,
> > whatever.
> >
> > If done right, a bunch of these reports could point to particular
> > changes to 

Re: [tor-relays] Decline in relays

[rasptor 4273]

My relay has gone off the consensus.
Fingerprint: E7FFF8C3D5736AB87215C5DB05620103033E69C3
Alias: rasptor4273
Am running Tor 0.2.5.14 on Debian, Raspberry Pi 2B. I upgraded to that
version on September 3rd.

I grepped through these:
https://collector.torproject.org/archive/relay-descriptors/consensuses/ and
the latest entry I found for my alias is in the file
./17/2017-09-17-13-00-00-consensus.

Not sure what other information I can provide. Do let me know if I can do
anything else to help troubleshoot.

Best,
Joep

On Mon, Oct 23, 2017 at 9:14 PM, George  wrote:

> David Goulet:
> > Hello everyone!
> >
> > Since July 2017, there has been a steady decline in relays from ~7k to
> now
> > ~6.5k. This is a bit unusual that is we don't see often such a steady
> behavior
> > of relays going offline (at least that I can remember...).
> >
> > It could certainly be something normal here. However, we shouldn't rule
> out a
> > bug in tor as well. The steadyness of the decline makes me a bit more
> worried
> > than usual.
> >
> > You can see the decline has started around July 2017:
> >
> > https://metrics.torproject.org/networksize.html?start=
> 2017-06-01=2017-10-23
> >
> > What happened around July in terms of tor release:
> >
> > 2017-06-08 09:35:17 -0400 802d30d9b7  (tag: tor-0.3.0.8)
> > 2017-06-08 09:47:44 -0400 e14006a545  (tag: tor-0.2.5.14)
> > 2017-06-08 09:47:58 -0400 aa89500225  (tag: tor-0.2.9.11)
> > 2017-06-08 09:55:28 -0400 f833164576  (tag: tor-0.2.4.29)
> > 2017-06-08 09:55:58 -0400 21a9e5371d  (tag: tor-0.2.6.12)
> > 2017-06-08 09:56:15 -0400 3db01d3b56  (tag: tor-0.2.7.8)
> > 2017-06-08 09:58:36 -0400 64ac28ef5d  (tag: tor-0.2.8.14)
> > 2017-06-08 10:15:41 -0400 dc47d936d4  (tag: tor-0.3.1.3-alpha)
> > ...
> > 2017-06-29 16:56:13 -0400 fab91a290d  (tag: tor-0.3.1.4-alpha)
> > 2017-06-29 17:03:23 -0400 22b3bf094e  (tag: tor-0.3.0.9)
> > ...
> > 2017-08-01 11:33:36 -0400 83389502ee  (tag: tor-0.3.1.5-alpha)
> > 2017-08-02 11:50:57 -0400 c33db290a9  (tag: tor-0.3.0.10)
> >
> > Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life.
> >
> > That being said, I don't have an easy way to list which relays went
> offline
> > during the decline (since July basically) to see if a common pattern
> emerges.
> >
> > So few things. First, if anyone on this list noticed that their relay
> went off
> > the consensus while still having tor running, it is a good time to
> inform this
> > thread :).
> >
> > Second, anyone could have an idea of what possibly is going on that is
> have
> > one or more theories. Even better, if you have some tooling to try to
> list
> > which relays went offline, that would be _awesome_.
> >
> > Third, knowing what was the state of packaging in
> Debian/Redhat/Ubuntu/...
> > around July could be useful. What if a package in distro X is broken and
> the
> > update have been killing the relays? Or something like that...
> >
> > Last, looking at the dirauth would be a good idea. Basically, when did
> the
> > majority switched to 030 and then 031. Starting in July, what was the
> state of
> > the dirauth version?
> >
> > Any help is very welcome! Again, this decline could be from natural
> cause but
> > for now I just don't want to rule out an issue in tor or packaging.
>
> (Replying to OP since it went OT)
>
> As some of you know, TDP did a little suite of shell scripts based on
> OONI data to look at diversity statistics:
>
> https://torbsd.github.io/oostats.html
>
> With the source here for further tinkering:
>
> https://github.com/torbsd/tdp-onion-stats/
>
> Maybe something we could look at is "exception reports", which in some
> industries means regular reports that look at anomalies or "exceptions"
> which display out-of-the-ordinary statistics, generally prompting some
> sort of action.
>
> In other words, daily reports would be run on, say, bw consensus by
> country, and if there was some statistically significant change over N
> periods of time, it would be noted. Or if a particular OS drops or
> jumps. Or if a particular AS jumps or declines for relays, bridges,
> whatever.
>
> If done right, a bunch of these reports could point to particular
> changes to the network that need further investigation, and in some
> cases, might quickly point to the related issue.  Eg, countryX shutdown
> ISP with a particular AS number, etc.
>
> The more reports coupled with careful optimization over time could
> become an alarm system for Tor network changes, instead of just "er,
> such-and-such distro didnt update their packages then, I just found out
> in git."
>
> Thoughts?
>
> g
>
>
> --
>
>
> 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
>
>
> ___
> 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

Re: [tor-relays] tor network change and event detection

[nusenu]

> Was it picked up by any alerts earlier, especially those two big and
> short-term drops?

I assume you mean the bridges line, they didn't remain unnoticed [1] and
you can find their explanation here:
https://metrics.torproject.org/news.html


[1]
https://lists.torproject.org/pipermail/metrics-team/2017-August/000440.html

-- 
https://mastodon.social/@nusenu
twitter: @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 network change and event detection

[George]

nusenu:
>> As some of you know, TDP did a little suite of shell scripts based on
>> OONI data to look at diversity statistics:
> 
> I think you mean onionoo (not OONI).

Yes.  Sloppy on details when thinking conceptually sometimes :)

> 
>> In other words, daily reports would be run on, say, bw consensus by
>> country, and if there was some statistically significant change over N
>> periods of time, it would be noted. Or if a particular OS drops or
>> jumps. Or if a particular AS jumps or declines for relays, bridges,
>> whatever.
> 
> something related:
> 
> https://nusenu.github.io/OrNetRadar/
> as ML: https://lists.riseup.net/www/info/ornetradar
> 
> https://nusenu.github.io/OrNetStats/
> 
> 
> Then there is (will be) metrics-bot, I made some feature requests
> similar to your examples above here:
> 
> https://trac.torproject.org/projects/tor/ticket/23937#comment:1
> 
> 
> also related:
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-consensus-health

This is all good stuff, some of which I've seen before.  Really impressive.

Maybe I'm missing something from my quick view of above, but I'm
thinking about more general reports about the network, though.

For instance, the OP was about a decline in relays in July, but it's not
being noticed until late October.

https://metrics.torproject.org/networksize.html?start=2017-06-01=2017-10-23

Was it picked up by any alerts earlier, especially those two big and
short-term drops?

Exception reports are generally drastic changes that might be noticeable
with general changes of the full snapshot of the network and its nodes.

Let me give this a bit more thought, but thanks nusenu.

g

-- 


34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682



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 network change and event detection

[nusenu]

> As some of you know, TDP did a little suite of shell scripts based on
> OONI data to look at diversity statistics:

I think you mean onionoo (not OONI).

> In other words, daily reports would be run on, say, bw consensus by
> country, and if there was some statistically significant change over N
> periods of time, it would be noted. Or if a particular OS drops or
> jumps. Or if a particular AS jumps or declines for relays, bridges,
> whatever.

something related:

https://nusenu.github.io/OrNetRadar/
as ML: https://lists.riseup.net/www/info/ornetradar

https://nusenu.github.io/OrNetStats/


Then there is (will be) metrics-bot, I made some feature requests
similar to your examples above here:

https://trac.torproject.org/projects/tor/ticket/23937#comment:1


also related:
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-consensus-health

-- 
https://mastodon.social/@nusenu
twitter: @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] Decline in relays

[George]

David Goulet:
> Hello everyone!
> 
> Since July 2017, there has been a steady decline in relays from ~7k to now
> ~6.5k. This is a bit unusual that is we don't see often such a steady behavior
> of relays going offline (at least that I can remember...).
> 
> It could certainly be something normal here. However, we shouldn't rule out a
> bug in tor as well. The steadyness of the decline makes me a bit more worried
> than usual.
> 
> You can see the decline has started around July 2017:
> 
> https://metrics.torproject.org/networksize.html?start=2017-06-01=2017-10-23
> 
> What happened around July in terms of tor release:
> 
> 2017-06-08 09:35:17 -0400 802d30d9b7  (tag: tor-0.3.0.8)
> 2017-06-08 09:47:44 -0400 e14006a545  (tag: tor-0.2.5.14)
> 2017-06-08 09:47:58 -0400 aa89500225  (tag: tor-0.2.9.11)
> 2017-06-08 09:55:28 -0400 f833164576  (tag: tor-0.2.4.29)
> 2017-06-08 09:55:58 -0400 21a9e5371d  (tag: tor-0.2.6.12)
> 2017-06-08 09:56:15 -0400 3db01d3b56  (tag: tor-0.2.7.8)
> 2017-06-08 09:58:36 -0400 64ac28ef5d  (tag: tor-0.2.8.14)
> 2017-06-08 10:15:41 -0400 dc47d936d4  (tag: tor-0.3.1.3-alpha)
> ...
> 2017-06-29 16:56:13 -0400 fab91a290d  (tag: tor-0.3.1.4-alpha)
> 2017-06-29 17:03:23 -0400 22b3bf094e  (tag: tor-0.3.0.9)
> ...
> 2017-08-01 11:33:36 -0400 83389502ee  (tag: tor-0.3.1.5-alpha)
> 2017-08-02 11:50:57 -0400 c33db290a9  (tag: tor-0.3.0.10)
> 
> Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life.
> 
> That being said, I don't have an easy way to list which relays went offline
> during the decline (since July basically) to see if a common pattern emerges.
> 
> So few things. First, if anyone on this list noticed that their relay went off
> the consensus while still having tor running, it is a good time to inform this
> thread :).
> 
> Second, anyone could have an idea of what possibly is going on that is have
> one or more theories. Even better, if you have some tooling to try to list
> which relays went offline, that would be _awesome_.
> 
> Third, knowing what was the state of packaging in Debian/Redhat/Ubuntu/...
> around July could be useful. What if a package in distro X is broken and the
> update have been killing the relays? Or something like that...
> 
> Last, looking at the dirauth would be a good idea. Basically, when did the
> majority switched to 030 and then 031. Starting in July, what was the state of
> the dirauth version?
> 
> Any help is very welcome! Again, this decline could be from natural cause but
> for now I just don't want to rule out an issue in tor or packaging.

(Replying to OP since it went OT)

As some of you know, TDP did a little suite of shell scripts based on
OONI data to look at diversity statistics:

https://torbsd.github.io/oostats.html

With the source here for further tinkering:

https://github.com/torbsd/tdp-onion-stats/

Maybe something we could look at is "exception reports", which in some
industries means regular reports that look at anomalies or "exceptions"
which display out-of-the-ordinary statistics, generally prompting some
sort of action.

In other words, daily reports would be run on, say, bw consensus by
country, and if there was some statistically significant change over N
periods of time, it would be noted. Or if a particular OS drops or
jumps. Or if a particular AS jumps or declines for relays, bridges,
whatever.

If done right, a bunch of these reports could point to particular
changes to the network that need further investigation, and in some
cases, might quickly point to the related issue.  Eg, countryX shutdown
ISP with a particular AS number, etc.

The more reports coupled with careful optimization over time could
become an alarm system for Tor network changes, instead of just "er,
such-and-such distro didnt update their packages then, I just found out
in git."

Thoughts?

g


-- 


34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682



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] Decline in relays

[David Goulet]

On 23 Oct (09:37:31), Eli wrote:

> I can state the reason I stopped hosting my exit relay was due to tor rpm
> package not being up to date for CentOS 7. The last available version was
> considered out of date and no longer supported. So instead of running a
> relay that was potentially detrimental to the health of the tor network I
> shutdown the node.

I've just pinged our Fedora/CentOS packager, he pointed out this:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-abe6f98ebf

6 days ago, the latest up to date Tor LTS version was uploaded. :)

Big thanks for running a relay!

Cheers!
David

> 
> On Oct 23, 2017, 9:32 AM, at 9:32 AM, David Goulet  
> wrote:
> >Hello everyone!
> >
> >Since July 2017, there has been a steady decline in relays from ~7k to
> >now
> >~6.5k. This is a bit unusual that is we don't see often such a steady
> >behavior
> >of relays going offline (at least that I can remember...).
> >
> >It could certainly be something normal here. However, we shouldn't rule
> >out a
> >bug in tor as well. The steadyness of the decline makes me a bit more
> >worried
> >than usual.
> >
> >You can see the decline has started around July 2017:
> >
> >https://metrics.torproject.org/networksize.html?start=2017-06-01=2017-10-23
> >
> >What happened around July in terms of tor release:
> >
> >2017-06-08 09:35:17 -0400 802d30d9b7  (tag: tor-0.3.0.8)
> >2017-06-08 09:47:44 -0400 e14006a545  (tag: tor-0.2.5.14)
> >2017-06-08 09:47:58 -0400 aa89500225  (tag: tor-0.2.9.11)
> >2017-06-08 09:55:28 -0400 f833164576  (tag: tor-0.2.4.29)
> >2017-06-08 09:55:58 -0400 21a9e5371d  (tag: tor-0.2.6.12)
> >2017-06-08 09:56:15 -0400 3db01d3b56  (tag: tor-0.2.7.8)
> >2017-06-08 09:58:36 -0400 64ac28ef5d  (tag: tor-0.2.8.14)
> >2017-06-08 10:15:41 -0400 dc47d936d4  (tag: tor-0.3.1.3-alpha)
> >...
> >2017-06-29 16:56:13 -0400 fab91a290d  (tag: tor-0.3.1.4-alpha)
> >2017-06-29 17:03:23 -0400 22b3bf094e  (tag: tor-0.3.0.9)
> >...
> >2017-08-01 11:33:36 -0400 83389502ee  (tag: tor-0.3.1.5-alpha)
> >2017-08-02 11:50:57 -0400 c33db290a9  (tag: tor-0.3.0.10)
> >
> >Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life.
> >
> >That being said, I don't have an easy way to list which relays went
> >offline
> >during the decline (since July basically) to see if a common pattern
> >emerges.
> >
> >So few things. First, if anyone on this list noticed that their relay
> >went off
> >the consensus while still having tor running, it is a good time to
> >inform this
> >thread :).
> >
> >Second, anyone could have an idea of what possibly is going on that is
> >have
> >one or more theories. Even better, if you have some tooling to try to
> >list
> >which relays went offline, that would be _awesome_.
> >
> >Third, knowing what was the state of packaging in
> >Debian/Redhat/Ubuntu/...
> >around July could be useful. What if a package in distro X is broken
> >and the
> >update have been killing the relays? Or something like that...
> >
> >Last, looking at the dirauth would be a good idea. Basically, when did
> >the
> >majority switched to 030 and then 031. Starting in July, what was the
> >state of
> >the dirauth version?
> >
> >Any help is very welcome! Again, this decline could be from natural
> >cause but
> >for now I just don't want to rule out an issue in tor or packaging.
> >
> >Cheers!
> >David
> >
> >--
> >HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY=
> >
> >
> >
> >
> >___
> >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


-- 
HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY=


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

Re: [tor-relays] Decline in relays

[Eli]

I can state the reason I stopped hosting my exit relay was due to tor rpm 
package not being up to date for CentOS 7. The last available version was 
considered out of date and no longer supported. So instead of running a relay 
that was potentially detrimental to the health of the tor network I shutdown 
the node.

On Oct 23, 2017, 9:32 AM, at 9:32 AM, David Goulet  
wrote:
>Hello everyone!
>
>Since July 2017, there has been a steady decline in relays from ~7k to
>now
>~6.5k. This is a bit unusual that is we don't see often such a steady
>behavior
>of relays going offline (at least that I can remember...).
>
>It could certainly be something normal here. However, we shouldn't rule
>out a
>bug in tor as well. The steadyness of the decline makes me a bit more
>worried
>than usual.
>
>You can see the decline has started around July 2017:
>
>https://metrics.torproject.org/networksize.html?start=2017-06-01=2017-10-23
>
>What happened around July in terms of tor release:
>
>2017-06-08 09:35:17 -0400 802d30d9b7  (tag: tor-0.3.0.8)
>2017-06-08 09:47:44 -0400 e14006a545  (tag: tor-0.2.5.14)
>2017-06-08 09:47:58 -0400 aa89500225  (tag: tor-0.2.9.11)
>2017-06-08 09:55:28 -0400 f833164576  (tag: tor-0.2.4.29)
>2017-06-08 09:55:58 -0400 21a9e5371d  (tag: tor-0.2.6.12)
>2017-06-08 09:56:15 -0400 3db01d3b56  (tag: tor-0.2.7.8)
>2017-06-08 09:58:36 -0400 64ac28ef5d  (tag: tor-0.2.8.14)
>2017-06-08 10:15:41 -0400 dc47d936d4  (tag: tor-0.3.1.3-alpha)
>...
>2017-06-29 16:56:13 -0400 fab91a290d  (tag: tor-0.3.1.4-alpha)
>2017-06-29 17:03:23 -0400 22b3bf094e  (tag: tor-0.3.0.9)
>...
>2017-08-01 11:33:36 -0400 83389502ee  (tag: tor-0.3.1.5-alpha)
>2017-08-02 11:50:57 -0400 c33db290a9  (tag: tor-0.3.0.10)
>
>Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life.
>
>That being said, I don't have an easy way to list which relays went
>offline
>during the decline (since July basically) to see if a common pattern
>emerges.
>
>So few things. First, if anyone on this list noticed that their relay
>went off
>the consensus while still having tor running, it is a good time to
>inform this
>thread :).
>
>Second, anyone could have an idea of what possibly is going on that is
>have
>one or more theories. Even better, if you have some tooling to try to
>list
>which relays went offline, that would be _awesome_.
>
>Third, knowing what was the state of packaging in
>Debian/Redhat/Ubuntu/...
>around July could be useful. What if a package in distro X is broken
>and the
>update have been killing the relays? Or something like that...
>
>Last, looking at the dirauth would be a good idea. Basically, when did
>the
>majority switched to 030 and then 031. Starting in July, what was the
>state of
>the dirauth version?
>
>Any help is very welcome! Again, this decline could be from natural
>cause but
>for now I just don't want to rule out an issue in tor or packaging.
>
>Cheers!
>David
>
>--
>HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY=
>
>
>
>
>___
>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] Decline in relays

[David Goulet]

Hello everyone!

Since July 2017, there has been a steady decline in relays from ~7k to now
~6.5k. This is a bit unusual that is we don't see often such a steady behavior
of relays going offline (at least that I can remember...).

It could certainly be something normal here. However, we shouldn't rule out a
bug in tor as well. The steadyness of the decline makes me a bit more worried
than usual.

You can see the decline has started around July 2017:

https://metrics.torproject.org/networksize.html?start=2017-06-01=2017-10-23

What happened around July in terms of tor release:

2017-06-08 09:35:17 -0400 802d30d9b7  (tag: tor-0.3.0.8)
2017-06-08 09:47:44 -0400 e14006a545  (tag: tor-0.2.5.14)
2017-06-08 09:47:58 -0400 aa89500225  (tag: tor-0.2.9.11)
2017-06-08 09:55:28 -0400 f833164576  (tag: tor-0.2.4.29)
2017-06-08 09:55:58 -0400 21a9e5371d  (tag: tor-0.2.6.12)
2017-06-08 09:56:15 -0400 3db01d3b56  (tag: tor-0.2.7.8)
2017-06-08 09:58:36 -0400 64ac28ef5d  (tag: tor-0.2.8.14)
2017-06-08 10:15:41 -0400 dc47d936d4  (tag: tor-0.3.1.3-alpha)
...
2017-06-29 16:56:13 -0400 fab91a290d  (tag: tor-0.3.1.4-alpha)
2017-06-29 17:03:23 -0400 22b3bf094e  (tag: tor-0.3.0.9)
...
2017-08-01 11:33:36 -0400 83389502ee  (tag: tor-0.3.1.5-alpha)
2017-08-02 11:50:57 -0400 c33db290a9  (tag: tor-0.3.0.10)

Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life.

That being said, I don't have an easy way to list which relays went offline
during the decline (since July basically) to see if a common pattern emerges.

So few things. First, if anyone on this list noticed that their relay went off
the consensus while still having tor running, it is a good time to inform this
thread :).

Second, anyone could have an idea of what possibly is going on that is have
one or more theories. Even better, if you have some tooling to try to list
which relays went offline, that would be _awesome_.

Third, knowing what was the state of packaging in Debian/Redhat/Ubuntu/...
around July could be useful. What if a package in distro X is broken and the
update have been killing the relays? Or something like that...

Last, looking at the dirauth would be a good idea. Basically, when did the
majority switched to 030 and then 031. Starting in July, what was the state of
the dirauth version?

Any help is very welcome! Again, this decline could be from natural cause but
for now I just don't want to rule out an issue in tor or packaging.

Cheers!
David

-- 
HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY=


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