[tor-dev] Understanding the guard/md issue (#21969)

[George Kadianakis]

teor <teor2345 at gmail.com> writes:

>> On 29 Oct 2017, at 01:19, George Kadianakis <desnacked at riseup.net> wrote:
>> 
>> Hey Tim,
>> 
>> just wanted to ask a clarifying question wrt #21969.
>> 
>> First of all there are various forms of #21969 (aka the "missing
>> descriptors for some of our primary entry guards" issue). Sometimes it
>> occurs for 10 mins and then goes away, whereas for other people it
>> disables their service permanently (until restart). I call this the
>> hardcore case of #21969. It has happened to me and disabled my service
>> for days, and I've also seen it happen to other people (e.g. dgoulet).
>> 
>> So. We have found various md-related bugs and put them as children of
>> #21969. Do you think we have found the bugs that can cause the hardcore
>> case of #21969? That is, is any of these bugs (or a bug combo) capable
>> of permanently disabling an onion service?
>
> Yes, this bug is disabling:
>

Thanks for the reply, Tim.

> #23862, where we don't update guard state unless we have enough
> directory info.
>
> When tor gets in a state where it doesn't have enough directory info
> due to another bug, this makes sure it will never get out of that state.
> Because it will never mark its directory guards as up when it gets a
> new consensus, and therefore it will never fetch microdescs, find out
> it has enough directory info, and build circuits.
>

Hmm, just want to make sure I get this.

My understanding with #23862 is that Tor would never mark its directory
guards as up like you say, but it _would still_ fetch microdescs using
fallback directories because of the way
directory_pick_generic_dirserver() works. Isn't that the case?