[tor-bugs] #19570 [Core Tor/Tor]: Shared random round gets out of sync

[Tor Bug Tracker & Wiki]

#19570: Shared random round gets out of sync
--------------------------+------------------------------------
 Reporter:  teor          |          Owner:
     Type:  defect        |         Status:  needs_information
 Priority:  High          |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-sr        |  Actual Points:
Parent ID:                |         Points:  0.5
 Reviewer:                |        Sponsor:  SponsorR-must
--------------------------+------------------------------------

Comment (by asn):

 Replying to [ticket:19570 teor]:
 > I have two test directory authorities which disagree on which round it
 is. I think it's because one is voting every half hour (due to consensus
 failure), and the other is voting every hour. It could also be due to
 their start times.
 >
 > I started this test directory authority at 00:54:30 UTC
 > (Log times UTC+10)
 > `Jul 05 12:00:01.000 [info] sr_state_update(): SR: State prepared for
 upcoming voting period (2016-07-05 03:00:00). Upcoming phase is commit
 (counters: 3 commit & 0 reveal rounds).`
 >
 > I started another test directory authority at 01:47:52 UTC
 > (Log times are UTC)
 > `Jul 05 02:00:01.000 [info] sr_state_update(): SR: State prepared for
 upcoming voting period (2016-07-05 03:00:00). Upcoming phase is commit
 (counters: 2 commit & 0 reveal rounds).`
 >
 > Is this just a logging / counting issue, or a serious bug that could
 affect the consensus?

 This might indeed be a logging/counting issue and not a serious bug. The
 round counters that caused the confusion are just integer counters that
 get incremented everytime Tor calls `sr_state_update()`. The counters
 don't actually understand the SR protocol and that's what causes these
 inconsistencies.

 For example, if a dirauth does not have a consensus in its data directory
 at startup, it will call `sr_state_update()` one extra time, because it
 will go into ''emergency voting mode'', call `sr_state_update()` and set
 up its state to vote at `InitialVotingInterval`; that is at the half hour
 (e.g. at 02:30), instead of the next full hour (e.g. at 03:00). Then when
 that dirauth downloads a valid consensus, `sr_state_update()` will be
 called again and it will correct its state to vote on the next full hour
 (e.g. at 03:00) as it should.  So the dirauth without a consensus will
 call that function one extra time, and that's why the counter values can
 be inconsistent.

 To see if that's the case, please attach your `$ grep SR info.log`. :)

 ----

 WRT the voting issue that dgoulet mentioned, I think this is just a
 timezone confusion. Since the log timezones are in local time UTC+10, at
 12:00:01 when the message was logged it's actually 02:00:01UTC. So at that
 point it indeed makes sense to prepare our state for 03:00UTC. So I don't
 think there is an issue here.

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