tor-0.2.1.15-rc posts inappropriate descriptor update, resulting in eventual expiration from consen
-- Submitted on behalf of "Scott Bennett bennett@cs.niu.edu" --
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 bennett@cs.niu.edu
[Automatically added by flyspray2trac: Operating System: All]
Trac:
Username: Jon_Scream