[tor-bugs] #21415 [Core Tor/Tor]: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.

[Tor Bug Tracker & Wiki]

#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845:
select_entry_guard_for_circuit: Non-fatal assertion
!(!guard_has_descriptor(guard)) failed.
-----------------------------+------------------------------------
 Reporter:  cypherpunks      |          Owner:  nickm
     Type:  defect           |         Status:  needs_review
 Priority:  Medium           |      Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal           |     Resolution:
 Keywords:  review-group-16  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:  asn              |        Sponsor:
-----------------------------+------------------------------------
Changes (by asn):

 * status:  reopened => needs_review


Comment:

 OK, after about 4 hours of debugging, I present you a fix in my branch
 `bug21415_testfix`. We are dealing with a pretty hairy multi-component
 part of the codebase, so careful consideration is required.

 Here is the commit message that might help you:
 {{{
 The bridges+ipv6-min integration test has a client with bridges:
     Bridge 127.0.0.1:5003
     Bridge [::1]:5003
 which got stuck in
 guard_selection_have_enough_dir_info_to_build_circuits()
 because it couldn't find the descriptor of both bridges.

 Specifically, the guard_has_descriptor() function could not find the
 node_t of the [::1] bridge, because the [::1] bridge had no identity
 digest assigned to it.

 After further examination, it seems that during fetching the descriptor
 for our bridges, we used the CERTS cell to fill the identity digest of
 127.0.0.1:5003 properly. However, when we received a CERTS cell from
 [::1]:5003 we actually ignored its identity digest because the
 learned_router_identity() function was using
 get_configured_bridge_by_addr_port_digest() which was returning the
 127.0.0.1 bridge instead of the [::1] bridge (because it prioritizes
 digest matching over addrport matching).

 The fix replaces get_configured_bridge_by_addr_port_digest() with the
 recent get_configured_bridge_by_exact_addr_port_digest() function. It
 also relaxes the constraints of the
 get_configured_bridge_by_exact_addr_port_digest() function by making it
 return bridges whose identity digest is not yet known.

 By using the _exact_() function, learned_router_identity() actually
 fills in the identity digest of the [::1] bridge, which then allows
 guard_has_descriptor() to find the right node_t and verify that the
 descriptor is there.

 FWIW, in the bridges+ipv6-min test both 127.0.0.1 and [::1] bridges
 correspond to the same node_t, which I guess makes sense given that it's
 actually the same underlying bridge.
 }}}

 Please let me know what you think about this fix. I thought about
 unintended consequences of the mod in
 `get_configured_bridge_by_exact_addr_port_digest()` and
 `learned_router_identity()` but I couldn't find something bad.

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