Opened 9 years ago

Closed 8 years ago

Last modified 7 years ago

#1810 closed defect (fixed)

published new server descriptor but authorities dropped because cosmetic

Reported by: Trystero Owned by:
Priority: Very High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

yesterday my exit node was running but not relaying. no data in and out but huge jump in incoming connections.
i restarted Tor as suggested in irc chat and that normalize everything but today repeated the problem but with a difference.
yesterday - connections established but not relaying
today - connections established and relaying.
but both occurrences drop from the consensus.

lot49

Child Tickets

Change History (18)

comment:1 Changed 9 years ago by arma

It's not mentioned in any of the votes either.

Here's our hint, from moria1's logs:

Aug 07 00:44:40.914 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.
Aug 07 01:06:00.721 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.
Aug 07 01:18:40.696 [info] dirserv_add_descriptor(): Not replacing descriptor from 'lot49' (source: 69.163.34.69); differences are cosmetic.
Aug 07 01:27:21.478 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.
Aug 07 01:48:51.213 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.
Aug 07 02:09:30.515 [info] dirserv_add_descriptor(): Not replacing descriptor from 'lot49' (source: 69.163.34.69); differences are cosmetic.
Aug 07 02:10:11.153 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.
Aug 07 02:31:30.813 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.
Aug 07 02:52:51.334 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.

So what happened during these two publishes to make lot49 republish but to make moria1 think it didn't have anything new to say?

See also whichever bug it is where the Tor relay ought to recognize that its publish didn't take, and reschedule the new descriptor for the more suitable time.

comment:2 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.1-alpha
Priority: majornormal

Somewhere in the 0.2.3.x timeline we want to revamp the publish-retry logic a little bit anyway; let's try to make stuff more robust here then.

comment:3 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.1-alphaTor: 0.2.3.x-final

(The relay-side retry logic might turn out to be a backport candidate.)

comment:4 Changed 9 years ago by arma

Summary: drop from consensuspublished new server descriptor but authorities dropped because cosmetic

comment:5 Changed 8 years ago by arma

The authority side of the fix is imo #2479.

Leaving this trac entry in place though since we want to know why _relays_ are publishing new descriptors that aren't different enough from the old ones.

comment:6 Changed 8 years ago by Sebastian

Priority: normalmajor

rransom noticed the republication is caused by a sighup, which debian does daily. So, bad luck for the poor operator who runs on Debian.

The issue is that we end up calling set_onion_key() on each sighup, which calls mark_my_descriptor_dirty() unconditionally. This has another fun implication if I'm reading it right: we never actually rotate our onion key.

comment:7 Changed 8 years ago by rransom

Milestone: Tor: 0.2.3.x-finalTor: 0.2.2.x-final
Priority: majorcritical

comment:8 Changed 8 years ago by arma

What's the call path from do_hup() to set_onion_key()?

comment:9 Changed 8 years ago by Sebastian

do_hup() --> options_init_from_torrc() --> options_init_from_string() --> set_options() --> options_act() --> init_keys() --> set_onion_key()

comment:10 Changed 8 years ago by arma

what makes options_transition_affects_workers() return true?

comment:11 Changed 8 years ago by Sebastian

Status: newneeds_review

So, the first part of the bug is fixed in bug1810 in my repository. The onion key rotation path is not, which causes more subtleties.

comment:12 in reply to:  6 Changed 8 years ago by rransom

Replying to Sebastian:

The issue is that we end up calling set_onion_key() on each sighup, which calls mark_my_descriptor_dirty() unconditionally. This has another fun implication if I'm reading it right: we never actually rotate our onion key.

set_onion_key is only called from one line in init_keys, and init_keys clobbers onionkey_set_at immediately after that call, so I don't think the extra calls to set_onion_key prevent onion key rotation.

comment:13 Changed 8 years ago by arma

Merged. Thanks! (I modified your changes file a bit, to take out the part about onion key rotation)

I think maybe we should close this ticket, and if the symptoms reoccur we can either reopen it or open a new one?

comment:14 Changed 8 years ago by rransom

The ‘other part’ mentioned in the commit message may be that init_keys still marks the descriptor as dirty unconditionally.

comment:15 in reply to:  14 Changed 8 years ago by arma

Replying to rransom:

The ‘other part’ mentioned in the commit message may be that init_keys still marks the descriptor as dirty unconditionally.

I just opened #3263 for that one. Thanks.

comment:16 Changed 8 years ago by Sebastian

Resolution: fixed
Status: needs_reviewclosed

Right, that was the other part. If this happens again we should open a new ticket.

comment:17 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:18 Changed 7 years ago by nickm

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