[tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--------------------------+------------------------------------
 Reporter:  rubiate       |          Owner:
     Type:  defect        |         Status:  new
 Priority:  High          |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal        |     Resolution:
 Keywords:  regression    |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:21 arma]:
 > Replying to [comment:17 teor]:
 > > But at some exponent, the wait time becomes indistinguishable from
 failure.
 > > (Which is why we need to make sure requests trigger a new attempt.)
 >
 > It is good that we have the belt-and-suspenders fix in place where new
 client requests trigger a new attempt -- but that trick only works for
 clients. We should make sure that directory mirrors also have some way to
 reliably keep trying, and same for exit relays because of the
 should_refuse_unknown_exits() thing. Basically all of the reasons in
 directory_fetches_from_authorities().
 >
 > > I guess this essentially implements hibernate mode then?
 > >
 > > And we could just put the failure count up to something quite high,
 let's say, at most, the failure number at which tor is waiting for the
 average time between tor stable releases?
 >
 > It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here. Speaking
 of which. is there a place I should look to read about our current
 download design? I only know the one I wrote some years ago, and it looks
 like it's changed since then.

 Proposal 210 is close, but it's been modified by at least you, me, and
 andrea since then.

 > > Firstly, because they get incremented twice for each failure.
 >
 > I haven't looked into that one, but if so, can we open a new ticket for
 this (what looks like separate) bug?

 #20533

 > > And secondly, because the laptop was offline for 12? hours?
 >
 > Actually, I think I drove my consensus download failure count up to 8
 over the course of about ten minutes -- it launches each new try within a
 second of when the last one failed:
 > {{{
 > Oct 24 03:51:12.713 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap mirror networkstatus consensus download.
 > Oct 24 03:51:12.713 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:51:42.725 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:52:36.747 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:54:14.787 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:57:19.855 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 04:00:48.938 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > }}}
 >
 > My laptop was closed (asleep) for more than a day, so when it woke up
 its consensus was more than 24 hours old, so it immediately jumped to
 bootstrap mode for its downloads. Ten minutes later, it had given up
 permanently.

 That timing is off from what I would expect - when I designed it, it was:
 Fallbacks: 0, 1, 5, 16, 3600, ...
 Authorities: 10, 21, 3600, ...

 But if we're skipping two on every failure, it could become:
 Fallbacks: 0, (1 or 5 depending on exact failure timing), 3600, ...
 Authorities: 10, 3600, ...
 And if the client has all the authorities as down, I guess it won't even
 try them.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20499#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online