On 13 Jan 2016, at 10:33, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:


At 19:20 1/12/2016 +0100, Aeris wrote:
Are you *absoultely* certain that the config
was not fiddled with at the time of this event?

After grepping some logs, seems 13/12 was the day of a Tor
upgrade :

2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1
2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1

Timing is good compare to the 10:48:46 of the consensus !

But I don’t remember a config change after that,
perhaps only on /usr/share/tor/tor-service-defaults-torrc
or on a default config param change ?

And perhaps the Tor reboot cause the DirPort to
be temporarily disabled (seems not human, only
2s duration) ?

I wonder if the DirPort self-test finished ~62 seconds after the ORPort self-test?
(Or, strictly, after the first descriptor was submitted?)

That would explain the behaviour we're seeing here.
(And it shouldn't be grounds for exclusion as a fallback directory, let me see what I can do.)

The fallback directory update script uses the OnionOO field last_changed_address_or_port, which is implemented correctly: the relays in question did stop announcing their DirPort within the last 120 days.

In the fallback directories script, there doesn't seem to be any way to work around the special case where relays stop announcing their DirPort for a single descriptor/consensus because they have been restarted, and their DirPort self-test has not finished yet.

So I don't know if there's any way to fix this, apart from fixing the underlying issue with the relay code, and waiting 120 days for the previous upgrades to be old enough that they don't matter any more.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F