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