No graph update for my relay in ATLAS
Hi, it seems that the graph in ATLAS (1 month and 3 months) for my relay isn't updated any longer for the graph 'read.' and 'written bytes per second' (last info was of 2018-01-01). The graph for 'consensus weight', 'middle probability' etc. seems to be ok. During startup of TOR (running it on Windows 10 / x64) the DirPort and the ORPort is reachable. Any idea? Btw how long must the relay be 'up' to get the 'stable' or 'guard' flag granted. My relay is now online for 46 days -only restarted for a TOR release upgrade-. A change of the IP-adress seems to be handled fine by TOR. This change by the ISP occurs at least every 3 days or so). Thanks in advance and best regards Peter Relay TRUMPER FP: 12DFC9D1852979939D9317F57A857C80BC73165E
On Thu, 25 Jan 2018 19:06:40 +0000, Peter Ott wrote: ...
release upgrade-. A change of the IP-adress seems to be handled fine by TOR.
That is only true for the client side.
This change by the ISP occurs at least every 3 days or so).
Clients address guards by their IP address, and they try hard to only talk to their selected guard. If that guards hops to another address, they have no chance of noticing that and need to select another one. That makes your node pretty useless as a guard, and it shouldn't be elevated to guard status. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On 26 Jan 2018, at 05:18, Andreas Krey <a.krey@gmx.de> wrote:
On Thu, 25 Jan 2018 19:06:40 +0000, Peter Ott wrote: ... release upgrade-. A change of the IP-adress seems to be handled fine by TOR.
That is only true for the client side.
Tor relays autodetect changes in their IPv4 address, and publish a new descriptor containing the new address.
This change by the ISP occurs at least every 3 days or so).
Clients address guards by their IP address, and they try hard to only talk to their selected guard. If that guards hops to another address, they have no chance of noticing that and need to select another one.
When the client gets the new descriptor (1-4 hours after each change), it will use the new IP address. Until then, the client would use its other primary guard.
That makes your node pretty useless as a guard, and it shouldn't be elevated to guard status.
The directory authorities regularly check the reachability of each relay. When your relay changes IPv4 address, some authorities might find it unreachable before it finds out itself, and publishes a new descriptor. This is probably why your relay does not have the stable and guard flags. But your relay is still useful as a middle node. And it frees up guard bandwidth to be used for direct client connections. This is particularly useful right now, because guards are under extra load from some clients that were added in December. T
On Fri, 26 Jan 2018 08:40:46 +0000, teor wrote: ...
Clients address guards by their IP address, and they try hard to only talk to their selected guard. If that guards hops to another address, they have no chance of noticing that and need to select another one.
When the client gets the new descriptor (1-4 hours after each change), it will use the new IP address. Until then, the client would use its other primary guard.
Obviously, I need to read up on the spec before making comments. ...
This is probably why your relay does not have the stable and guard flags.
That isn't my node we're talking about here. But mine (5B1F0DAF378A1FAFCFD5FA9CDC66D1023DC0276E) lost guard status as well in december, and I have no idea as to why either - except possibly because of running a non-recommended tor version (i.e. too bleeding edge release branch state). That is fixed since two weeks or so, and the addresses never changed. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On 26 Jan 2018, at 18:23, Andreas Krey <a.krey@gmx.de> wrote:
But mine (5B1F0DAF378A1FAFCFD5FA9CDC66D1023DC0276E) lost guard status as well in december, and I have no idea as to why either - except possibly because of running a non-recommended tor version (i.e. too bleeding edge release branch state). That is fixed since two weeks or so, and the addresses never changed.
No, the tor version is not used to determine the guard flag. It's a combination of stability, speed, and age: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2444 Your relay may have been unstable with the extra client load in December. Or its bandwidth might have dropped. T
On 26 Jan 2018, at 05:06, Peter Ott <peter.ott@df7fe.de> wrote:
Hi, it seems that the graph in ATLAS (1 month and 3 months) for my relay isn’t updated any longer for the graph ‘read…’ and ‘written bytes per second’ (last info was of 2018-01-01). The graph for ‘consensus weight’, ‘middle probability’ etc. seems to be ok. During startup of TOR (running it on Windows 10 / x64) the DirPort and the ORPort is reachable. Any idea?
See: https://lists.torproject.org/pipermail/tor-relays/2018-January/014254.html T
participants (4)
-
Andreas Krey -
Peter Ott -
teor -
Toralf Förster