[tor-bugs] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  needs_review
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-relay, tor-dos, performance,     |  Actual Points:
  review-group-32, 033-must, review-group-34,    |
  033-triage-20180320, 033-included-20180320     |
Parent ID:                                       |         Points:
 Reviewer:  asn                                  |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by nickm):

 Replying to [comment:34 dgoulet]:
 > Replying to [comment:31 nickm]:
 > > So on the hash function: You can't use a memcpy(tor_addr_t) like that,
 because some of the bytes of the tor_addr_t can be unspecified.  I can fix
 that up.
 >
 > Oh damn because of the union, if it is a v4, we'll copy bunch of uninit
 bytes from the larger v6. I guess setting the size according to the family
 is the way to do it.
 >
 > > On unable_connect_since_ts: Do we ever clear this field (re-set it to
 zero) on success?  It seems like it just stays set forever.  If so maybe a
 better name would be something like "last_failed_connect_ts"?
 >
 > It is a timestamp, we don't need to reset it. It always being compared
 to a cutoff so even thought it is set once and never touched again, that
 is fine since it will at some point always pass the cutoff.

 Is it okay with you if I change the name anyway?  The problem is that the
 "since" implies a continuous condition.  If I say "I have been unable to
 eat broccoli since 1982", it does not mean only that in 1982 I failed to
 eat broccoli: it also means that at every time since 1982, I have also
 been unable to eat broccoli.

 > >  Oh, and one more thing I noticed: It is not enough to just check
 "node_get_pref_orport(node, &node_addr_port);" -- the node may have
 multiple addresses, and "pref" just returns the one you would prefer to
 use yourself.
 >
 > Not sure it is a problem here. We use `node_get_pref_orport()` only to
 make sure the or connection we are about to note down as a failure matches
 the `node_t` we have from the identity digest. In this case, we use the
 node_t to keep the timestamp. If it doesn't match (because other port/addr
 for the identity), we note it down as a "unknown".
 >
 > This ends up to be the same result but just more precisely indexed by
 addr + port + digest always.

 But the preferred address can change while Tor is running, I think, based
 on configuration options. That would make the value cached in the node
 become incorrect, and that's why I think we should maybe just not have
 this in the node_t at all.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24767#comment:36>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online