[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #19570 [Core Tor/Tor]: Shared random round gets out of sync
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs