[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 arma):

 To give some other context to folks reading this ticket, here is some more
 debugging detail (all from my Tor client that has been opting not to
 retrieve a new consensus for the past week+):

 I set a breakpoint on fetch_networkstatus_callback, and learned that
 prefer_mirrors is 1, and we_are_bootstrapping is 1.
 should_delay_dir_fetches() was 0. It called update_networkstatus_downloads
 as expected.

 Then I set a breakpoint on update_consensus_networkstatus_downloads. Again
 we_are_bootstrapping is 1. use_multi_conn alas is <optimized out>, but
 looking at the function, I assume it's 1 for me. The first round through
 the loop, for vanilla consensus flavor, we_want_to_fetch_flavor() is no,
 so I move on to the second round through the loop. I don't know how
 {{{c = networkstatus_get_latest_consensus_by_flavor(i);}}} goes because
 "print c" also says <optimized out>, but it looks like it runs
 {{{time_to_download_next_consensus[i] = now;}}} next, so I can assume that
 c was NULL. Then it keeps going through the function until it calls
 update_consensus_bootstrap_multiple_downloads(). Looks plausible.

 So I set a breakpoint on update_consensus_bootstrap_multiple_downloads,
 which was trickier than I would have wanted since it looks like my
 compiler inlined it into update_consensus_networkstatus_downloads. But it
 looks like it does make two calls to
 update_consensus_bootstrap_attempt_downloads -- one with dls_f, and the
 next with dls_a.

 So I set a breakpoint on update_consensus_bootstrap_attempt_downloads. It
 sets max_dl_tries to 7, which makes sense since I see it there in
 config.c, set to default to 7.

 Now it gets interesting:
 {{{
 (gdb) print *dls
 $3 = {next_attempt_at = 1477295479, n_download_failures = 0 '\000',
   n_download_attempts = 8 '\b', schedule = DL_SCHED_CONSENSUS,
   want_authority = DL_WANT_ANY_DIRSERVER,
   increment_on = DL_SCHED_INCREMENT_ATTEMPT,
   backoff = DL_SCHED_RANDOM_EXPONENTIAL, last_backoff_position = 8 '\b',
   last_delay_used = 7}
 }}}

 n_download_attempts is 8, and max_dl_tries is 7. I wonder where this is
 going!

 Turns out download_status_is_ready() is no fun to gdb in because it's an
 inline tucked into directory.h, but looking at the code, it seems clear it
 returns 0, i.e. not ready. Then the function exits.

 Then the same thing happens with the
 update_consensus_bootstrap_attempt_downloads call that was for dls_a.

 Conclusion, I somehow failed 8 times to get a consensus, and now I will
 never try again.

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