[tor-relays] probable FallbackDir relay determination bug

[starlight.2016q1 at binnacle.cx]

Dug into the situation Aeris reported where his
kitten1 relay was nixed off the fallback
directory list due to a single consensus
where the dir-port was published as zero.

Quickly found three additional very fast
very stable relays where the same thing
happened:

BF0FB582E37F738CD33C3651125F2772705BB8E8 12-28:17 quadhead
C43FA6474A9F071E9120DF63ED6EB8FDBA105234 12-25:03 ArachnideFR5
5665A3904C89E22E971305EE8C1997BCA4123C69 11-15:18 GermanCraft

In each case the V2Dir flag and DirPort are
removed for a single consensus interval
and then restored on the next consensus.
Appears that a daemon restart is the
trigger.  Version update not required.

Several possible causes, but the one that
comes to mind is the daemon could be briefly
pushing a descriptor with V2Dir inactive
while completing the reacahability
test for that port.

This deserves to be researched further and
mitigated.  A possible solution is to have
the script tolerate a single consensus
with V2Dir removed and a reset uptime.
Alternately the daemon could not push
a non-V2Dir descriptor during restart and
wait for the reacahability determination.

I don't know enough about it to be sure
the problem isn't something else.


At 19:20 1/12/2016 +0100, Aeris wrote:
>> Are you *absolutely* 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) ?
>
>Regards,
>-- 
>Aeris