[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