[tor-bugs] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  regression?, guard-selection,        |  Actual Points:
  dirauth                                        |
Parent ID:  #21573                               |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by dgoulet):

 * priority:  Medium => Very High
 * keywords:  regression?, guard-selection => regression?, guard-selection,
     dirauth


Comment:

 I can still hit that on master. This seems to be caused only by authority
 who can't pick a node for a circuit and this shows up:

 {{{
 Nov 16 09:27:50.380 [info] router_choose_random_node(): We couldn't find
 any live, fast, stable, guard routers; falling back to list of all
 routers.
 }}}

 I've added more logging and when they need a Guard, no nodes are
 considered Guards by any of the authorities leading to a probability of
 picking the same nodes twice in the path selection because tor is falling
 back to all nodes. Below are logs I've added within
 `nodes_is_unreliable()` called by
 `router_choose_random_node()->router_add_running_nodes_to_smartlist()`:

 {{{
 Nov 16 10:07:24.018 [warn] Node
 $B6813ACD5E30C9560CB8F3CAAE08EB1A9643FFE7~test002a at 127.0.0.1 is stable:
 1, is fast: 1, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $B6813ACD5E30C9560CB8F3CAAE08EB1A9643FFE7~test002a at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $24F57B943178DA7D1351F9566FDBD0620B2921CF~test000a at 127.0.0.1 is stable:
 1, is fast: 1, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $24F57B943178DA7D1351F9566FDBD0620B2921CF~test000a at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $A183E34C4F3465994DC8D69378A05F1B43141AF3~test003ba at 127.0.0.1 is
 stable: 1, is fast: 1, is possible guard: 0. We needed: Uptime, Capacity,
 Guard
 Nov 16 10:07:24.018 [warn] node
 $A183E34C4F3465994DC8D69378A05F1B43141AF3~test003ba at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] node
 $492A22ABAD8203EA2B6A10076F251AC50AB1EFE0~test001a at 127.0.0.1
 (is_runnig: 0, is_valid: 1)
 Nov 16 10:07:24.018 [warn] Node
 $01D04CBA14565AA7EFC4612F5B388B07802475AC~test004r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $01D04CBA14565AA7EFC4612F5B388B07802475AC~test004r at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $70CAC7E209998F7B073F3C13950BDE2787231D18~test005r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $70CAC7E209998F7B073F3C13950BDE2787231D18~test005r at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $2836767EF7120AF306B8A1AE87E364073334B247~test006r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $2836767EF7120AF306B8A1AE87E364073334B247~test006r at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $D1657CB2A8D479F2D5D617819326C49FBB6D1133~test007r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $D1657CB2A8D479F2D5D617819326C49FBB6D1133~test007r at 127.0.0.1 is
 unreliable
 }}}

 You can see that all `is_possible_guard` equals 0 when "Guard" was needed
 (or `need_guard = 1`). Which btw leads to this warning on the other relays
 when this happens:

 {{{
 Nov 16 10:19:16.664 [warn] connection_edge_process_relay_cell (away from
 origin) failed.
 Nov 16 10:19:16.664 [warn] circuit_receive_relay_cell (forward) failed.
 Closing.
 }}}

 That is something I've been seeing quite a bit on my test relay recently
 on the real network. So I think this might affect authorities outside
 `TestingNetwork`.

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