On 16 Dec 2018, at 17:01, starlight.2018q2@binnacle.cx wrote:

The cause is

https://gitweb.torproject.org/tor.git/commit/?id=78e177d622f5f3b24023d04458f5948275a44766

https://trac.torproject.org/projects/tor/ticket/24803

Would be appreciated if the Tor project published outputs
of UpdateFallbackDirs.py job runs used when rebuilding
the list.  Thus operators who have expended effort to keep
their relays eligible will know why when dropped.

We usually attach the logs to the relevant ticket.

This time, I saved the logs, but accidentally overwrote them.
And I didn't ask Colin to attach his logs.

We'll try to do better next time: I've added a note on the ticket
for 2019.

On 17 Dec 2018, at 10:45, starlight.2018q2@binnacle.cx wrote:

Ran the script: output is attached to this message for anyone
interested.  Live-network test results will vary by time and by
the location of tester.  Attached run was made over Tor
itself using 'torsocks'.

Thanks!

I was bit by having disabled the unencrypted DIR port for
one day recently as an experiment.

We rely on onionoo's last changed field:
https://metrics.torproject.org/onionoo.html#details_relay_last_changed_address_or_port

Changing or removing a published address or port resets the
last changed date. Adding an IPv6 address does not reset the
last changed date.

I realise that it's disappointing for relay operators to lose a flag.
But we're not too worried if a fallback drops out of the list for a
release or two: changing the fallback list regularly makes it
harder to block. And that's good for users.

T