tor-0.2.1.15-rc posts inappropriate descriptor update, resulting in eventual expiration from consen
-- Submitted on behalf of "Scott Bennett firstname.lastname@example.org" --
If a currently valid descriptor (#1) is on file at the authorities based upon the following data rate information from torrc:
BandwidthRate 100 KB BandwidthBurst 140 KB MaxAdvertisedBandwidth 85 KB and torrc is changed to read: BandwidthRate 85 KB BandwidthBurst 140 KB and no other torrc information has changed and the observed peak ten-second data rate in the previous 24 hours is unchanged since the publication of descriptor #1, a SIGHUP sent to tor causes a new descriptor (#2) to be posted to the authorities, where the only changed information is the publication timestamp. The authorities then reject descriptor #2 as "not new". The tor relay, however, has changed its own idea of when the next descriptor update should be posted to ~18 hours later than the timestamp on #2. At ~18 hours after the posting of descriptor #1, the authorities assume for the next consensus vote that the relay is no longer running because they have not received an update around ~18 hours from the posting of #1. This results in the relay being dropped from consensus documents until the relay posts an update ~18 hours from the timestamp of #2. This can cause a running tor relay to be dropped inappropriately from the consensus documents for many hours before the situation is corrected. Relays should not post early descriptor updates that will be rejected by the authorities, or alternatively, relays should not reset their 18-hour timers for descriptor updates until a majority of the authorities has accepted the new updates. This bug may also be related to bug report #962.
Submitted by: Scott Bennett email@example.com
[Automatically added by flyspray2trac: Operating System: All]