Opened 10 years ago

Last modified 7 years ago

#1026 closed defect (Fixed)

tor-0.2.1.15-rc posts inappropriate descriptor update, resulting in eventual expiration from consen

Reported by: Jon_Scream Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.0.35
Severity: Keywords:
Cc: Jon_Scream, karsten, nickm, Sebastian, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

-- Submitted on behalf of "Scott Bennett <bennett@…>" --

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@…>

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (10)

comment:1 Changed 10 years ago by Sebastian

hm. This should have been fixed in 8390787a...

I wonder why it isn't

comment:2 Changed 10 years ago by arma

I agree. It looks like exactly bug 962.

I wonder if the "0.2.1.15-rc" part of this means that the bug report
was made long ago, before enough authorities upgraded to 0.2.1.14-rc
that a majority of them would accept the new descriptor.

comment:3 Changed 10 years ago by Sebastian

I see the problem now. The descriptor doesn't change,
since before, maxadvertisedbandwidth was set to 85 KB. Now,
Bandwidthrate is set to 85 KB, so the client thinks the descriptor
is new, and the authority doesn't see a changed value, so it thinks
the descriptor is not new.

I'm unsure this is worth fixing for now, since we seem to plan to
alter that behaviour for 0.2.2.x (where relays notice themselves
when authorities dropped their descriptor on the floor, so they send
an update sooner).

What do you think, Roger?

comment:4 Changed 10 years ago by Sebastian

Nick thinks it's worthwile to fix. Will give it a try.

comment:5 Changed 10 years ago by Sebastian

comment:6 Changed 10 years ago by nickm

The latest bug1026 branch looks like a good change to make, but there's a more general problem here too: If the
authority rejects an upload as "not new", perhaps we should send it a new descriptor in less time than if the
upload had been accepted.

comment:7 Changed 10 years ago by Sebastian

right, that more general problem is not forgotten. We agreed earlier
to not do this in 0.2.1.x though, so I will at some point work on it
for 0.2.2.x if nobody else picks it up

comment:8 Changed 10 years ago by arma

I put Sebastian's fix into 0.2.1.19.

comment:9 Changed 10 years ago by Sebastian

flyspray2trac: bug closed.

comment:10 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.