#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed -----------------------------+------------------------------------ Reporter: cypherpunks | Owner: (none) Type: defect | Status: new Priority: Medium | Milestone: Tor: 0.3.2.x-final Component: Core Tor/Tor | Version: Tor: 0.3.2.1-alpha Severity: Normal | Resolution: Keywords: prop224, tor-hs | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: -----------------------------+------------------------------------
Comment (by dgoulet): Comment from the code: {{{ status = hs_client_refetch_hsdesc(&edge_conn->hs_ident->identity_pk); if (BUG(status == HS_CLIENT_FETCH_HAVE_DESC)) { /* This case is unique because it can NOT happen in theory. Once we get * a new descriptor, the HS client subsystem is notified immediately and * the connections waiting for it are handled which means the state will * change from renddesc wait state. Log this and continue to next * connection. */ continue; } }}} So, I think it is a wrong logic. Consider the following case: Imagine your client has fetched the descriptor for a service and at some point, all intro points weren't usable or in other words the intro points rotated and the client now has to fetch a new descriptor. Then this suspend happens while waiting for the descriptor fetch. We come back from suspend, the clock jumps 2000 seconds (33 minutes) and `rend_cache_failure_clean_callback()` is called (it is an housekeeping function which runs every 30 seconds). It cleans up the intro point failure cache (lifetime of entries are 2 minutes). Which means that the descriptor we have in the cache now suddenly is considered "usable". During that waiting period for the descriptor, a new consensus comes in so we have new directory information and we end up in retrying all pending SOCKS connection waiting for a descriptor `retry_all_socks_conn_waiting_for_desc()` that might have been hold back in the first place because we were missing directory information. Then, the BUG() is hit if we try a refetch for a service but for which we already have a descriptor. And that descriptor became usable after the suspend. So this means that the `BUG()` should not be there and be considered possible to have that situation. And extra bonus point, this should actually be a special case that we handle for which we try to attach the connection to a circuit instead of leaving it in limbo in `RENDDESC_WAIT` state and timing out after 120 seconds. In short, put the SOCKS conn in circuit wait state and try to attach it if we have a usable descriptor. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24610#comment:2> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs