[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_review
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:
--------------------------+------------------------------------
Comment (by asn):
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 from combining the two log files:
0) Everything was going great with Tor. It was connecting to a few HSes
(both v2 and v3s) just fine until 14:04:28.000. And then the clock skew
happened: `Dec 29 00:10:43.000 [notice] Your system clock just jumped
36372 seconds forward; assuming established circuits no longer work.`.
1) After the clock skew, Tor no longer has a live consensus, but it still
wants to connect to the HSv3s it has the descriptors for.
2) However, `hs_cache_lookup_as_client()` **cannot see** the cached
descriptors because it calls `cached_client_descriptor_has_expired` which
claims that the **descriptor is expired if there is no live consensus**!
`[info] can_client_refetch_desc(): Can't fetch descriptor for service
$onion_service. Stalling connection`
2) The SOCKS connection is now stalled with `AP_CONN_STATE_RENDDESC_WAIT`
because of (1).
4) Then after a bit we get a live 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 which is ''that a descriptor cannot be seen when the
consensus is not live'', is probably also the issue of the original
poster, 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 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