Roger Dingledine arma@torproject.org wrote:

On Fri, Jan 29, 2021 at 11:32:44AM +0100, raltullou@posteo.org wrote:

...

• At the beginning of January the relay seems to have lost the guard flag
• A week ago I checked and noticed that the relay had also lost the stable

flag despite having an uptime of >2 months at that point

• A week ago I rebooted the server but the situations hasn't changed - flags

are still gone

Some of the directory authorities have restarted many times in the past week, and each restart impacts their view of whether other relays are stable. In theory it should impact all the views equally (it's like there was a blip in the matrix but it was an equal blip for everybody), but in practice, maybe the math doesn't make it actually equal.

IOW, authority relays should not receive an Authority flag until they have sufficient uptime to judge correctly? Say, ten days or more?

...

• metrics.torproject graphs show that the server has been transmitting data

the entire time - so it doesn't seem like I missed some downtime

The graphs on relay-search are visualizing data that is self-reported by the relay. So from the relay's perspective there was no downtime, but that doesn't give us much hint about whether the directory authorities found the relay consistently reachable.

Another hint I find useful is to look at the individual votes from the directory authorities. One way to do that is to go to the bottom of https://consensus-health.torproject.org/#relayinfo and put in your nickname.

Or, as an alternative to the above proposal, newly awakened authorities' votes regarding time-dependent flags should be ignored by other authorities until the newly awakened have been awake at least, say, ten days? That would seem a minimum time appropriate for them to give valid judgments on the matter of time-dependent flags.

...

• Serverlogs show no problems
• Relay has been running continuously for almost 4 years and only gets

rebooted for kernel/tor upgrades -> so uptime and MTBF should not be a problem

Is there a problem on my side? Is there anything I can do or check?

One part that I would look into more is the IPv6 connectivity. Maybe that address is intermittent? If it is, then the relay would mostly continue to work as normal (because clients mostly use IPv4), but the subset of the dir auths that checks IPv6 reachability would consider that instability to be a short downtime.

Until IPv6 addresses are used by other relays to forward traffic, this seems a totally inappropriate criterion for determining reachability.

...

It is a fallback relay - is it still useful as such?

It is still useful yes.

Well, at least there is that, thank goodness. And at least I finally have a plausible explanation for the authorities' seemingly bizarre behavior over the past many moons in which they appear to be awarding, then withholding, then awarding, then withholding various flags, including HSDir, Stable, and even Fast, at random when my relay has been up and unfiddled with the whole time from what I have been able to see, and without any apparent rhyme or reason. I had given up trying to figure out what the authorities were doing, much less why, and therefore had stopped giving a dam about it. That situation, in combination with the involvement in the tor project of very vocal persons lacking apparent comprehension of the basic relationships between hardware, firmware, supervisory (i.e., privileged) software, and application software w.r.t. security matters, led me to stop providing a relay for about a year. I finally decided to return it to service, but have mostly stopped reading the overly chatty tor-relays list and any worry over additional security issues w.r.t. tor. I take care of my relay the best I know how with one exception on the authority of Roger Dingledine and leave it at that. Because I don't like accepting such things on authority, rather than proof or at least damned good evidence and reason, I mostly stopped caring, which is a real drag because I once was convinced that tor was a truly good effort to provide what should have been designed into the Internet in the first place. Unfortunately, there appear to be still no viable alternatives available.

Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

Toralf F?rster toralf.foerster@gmx.de wrote:

On 1/30/21 5:59 AM, Scott Bennett wrote:

...

  Or, as an alternative to the above proposal, newly awakened authorities'

votes regarding time-dependent flags should be ignored by other authorities until the newly awakened have been awake at least, say, ten days?

I do wonder if this helps if all authorities suffer from the same issue/architectural fla/DDos/bug ?

Well, at least some of us currently see that a majority of the authorities *do* suffer from the bug that Roger described. That bug does seem to provide some impairment to the performance of the tor network by causing loads to be distributed based upon faulty information in consensus documents. The network is presumably large enough now that such impairment is likely to be difficult to detect on the larger scales, but is being noticed by individual relay operators and our observations posted here. There was a time when the rule stated was that the different authorities must run different versions of tor in hopes of avoiding that sort of thing, but of course, tor versions are still susceptible to including the same bugs in many versions. I doubt that there is a perfect solution, but authorities can be configured with many overrides for standard operating parameters already. Either of the modifications that I proposed could well be implemented with a way for the project to temporarily override it in emergencies that would otherwise leave over half of the authority relays in a non-voting state simultaneously, for example. Also, note that the HSDir flag is withheld until a relay completes a minimum of 96 hours of uptime. Does that restriction currently apply to authorities as well? If so, then it provides an example of how applying time-dependent limits to the privileges of authorities should work.

Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

raltullou@posteo.org wrote:

Am 30.01.2021 05:59 schrieb Scott Bennett:

...

Roger Dingledine arma@torproject.org wrote:

...

...

It is a fallback relay - is it still useful as such?

It is still useful yes.

 Well, at least there is that, thank goodness.  And at least I 

finally have a plausible explanation for the authorities' seemingly bizarre behavior over the past many moons in which they appear to be awarding, then withholding, then awarding, then withholding various flags, including HSDir, Stable, and even Fast, at random when my relay has been up and unfiddled with the whole time from what I have been able to see, and without any apparent rhyme or reason. I had given up trying to figure out what the authorities were doing, much less why, and therefore had stopped giving a dam about it. That situation, in combination with the involvement in the tor project of very vocal persons lacking apparent comprehension of the basic relationships between hardware, firmware, supervisory (i.e., privileged) software, and application software w.r.t. security matters, led me to stop providing a relay for about a year. I finally decided to return it to service, but have mostly stopped reading the overly chatty tor-relays list and any worry over additional security issues w.r.t. tor. I take care of my relay the best I know how with one exception on the authority of Roger Dingledine and leave it at that. Because I don't like accepting such things on authority, rather than proof or at least damned good evidence and reason, I mostly stopped caring, which is a real drag because I once was convinced that tor was a truly good effort to provide what should have been designed into the Internet in the first place. Unfortunately, there appear to be still no viable alternatives available.

It's been another week and the flags are all back. I'm not aware of anything I did to loose them for a month and I din't do anything to get them back. For me that just just means I'll take your advice and start caring less ?_(?)_/?.

Thanks for your help everyone and I hope the underlying problem get fixed soon.

The following popped up almost an hour and a half ago in my relay's log file.

Feb 13 07:27:54.947 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.

Two milliseconds later it said,

Feb 13 07:27:54.949 [notice] Our directory information is no longer up-to-date enough to build circuits: We need more microdescriptors: we have 0/6708, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) Feb 13 07:27:54.949 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6708, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)

Is it telling the truth? Was there really an hour when the consensus contained no Exit flags in the entire file?

Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************