[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #28669 [Core Tor/Tor]: Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc



#28669: Bug: ../src/feature/hs/hs_client.c:280:
retry_all_socks_conn_waiting_for_desc
--------------------------+------------------------------------
 Reporter:  traumschule   |          Owner:  (none)
     Type:  defect        |         Status:  needs_revision
 Priority:  Medium        |      Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:                |         Points:
 Reviewer:  asn           |        Sponsor:
--------------------------+------------------------------------
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Given the latest information from traumschule, I have more doubts that the
 comment:3 theory is what's causing the issue here.

 Here is another theory:

 0) The logs start with a HUPed Tor with no live consensus.

 1) Tor wants to reach an HSv3 but could not fetch HS desc because of lack
 of live consensus: `[info] can_client_refetch_desc(): Can't fetch
 descriptor for service $onion_service. Stalling connection.` (log msg is
 stripped because of a wide regexp).

 2) The SOCKS connection is now stalled with `AP_CONN_STATE_RENDDESC_WAIT`
 because of (1).

 3) My theory is that Tor **had the HS desc all along** (from before the
 HUP) but still `hs_cache_lookup_as_client()` **could not see it** because
 it calls `cached_client_descriptor_has_expired` which claims that the
 **descriptor is expired if there is no live consensus!

 4) Then after a bit we get a consensus and
 `retry_all_socks_conn_waiting_for_desc()` gets called, this brings up the
 SOCKS connection from (2) which is still blocked at
 `AP_CONN_STATE_RENDDESC_WAIT`. However, now the descriptor is no longer
 expired because we have a live consensus, and hence there is a valid HS
 desc in the cache and hence the bug triggers.

 ----

 The same issue (where Tor could not see the cached HS desc because of no
 live consensus) was also probably the issue of the original poster with
 the clock skew, so perhaps we can simplify David's patch by not
 introducing `mark_conn_as_waiting_for_circuit()` and calling it when this
 branch triggers. But we might still want to remove the Bug() from there.

 Or is there something more elegant to do here?

 Removing from needs_revision to figure out next steps.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28669#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