#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs