Re: [tor-bugs] #21242 [Core Tor/Tor]: Start-up error

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#21242: Start-up error
--------------------------+------------------------------------
 Reporter:  Felixix       |          Owner:  asn
     Type:  defect        |         Status:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by asn):

 Thanks for the bug report.

 I did some digging here to see what's going on. Unfortunately, I think we
 are missing info to 100% determine what happened. Some debug/info logs
 would help, but anyway here is what I found. tl;dr I think we are missing
 the desc or the md of the node in question, and the guard code does not
 care.

 The code in question is:
 {{{
   } else if (cur_len == 0) { /* picking first node */
     const node_t *r = choose_good_entry_server(purpose, state,
                                                &circ->guard_state);
     if (r) {
       /* If we're a client, use the preferred address rather than the
          primary address, for potentially connecting to an IPv6 OR
          port. Servers always want the primary (IPv4) address. */
       int client = (server_mode(get_options()) == 0);
       /* ! client */
       info = extend_info_from_node(r, client);
       /* Clients can fail to find an allowed address */
       /* edw to kako */
       tor_assert(info || client);
     }
 }}}

 In this bug report, we are dealing with a relay, so `client` is false
 above. Now let's dig into `extend_info_from_node()` to see what made it
 return NULL:

 Given the fact that there are no `warn` logs, there are only two `return
 NULL` codepaths that we could have taken. Either this:
 {{{
   if (node->ri == NULL && (node->rs == NULL || node->md == NULL))
     return NULL;
 }}}
 or the final:
 {{{
   else
     return NULL;
 }}}

 IIUC, in the latter case we know that `valid_addr` was set (otherwise we
 would get warn), so we can only reach the above two codepaths if we are
 missing some crucial information about the node: either `node->ri` or
 `node->rs` or `node->md`.

 So my theory is that perhaps the new guard node code is not making sure
 that nodes have descriptors or microdescriptors? I see that in the legacy
 guard code we used to do this in `entry_is_live`:
 {{{
   if (need_descriptor && !node_has_descriptor(node)) {
     *msg = "no descriptor";
     return NULL;
   }
 }}}
 but we are not doing this anywhere in our current guard code. Could it be
 that this assert occurs when we are missing the descriptor of a node that
 is in the consensus (and we are in server mode)?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21242#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs