#19969: tor client does not immediately open new circuits after standby
--------------------------+------------------------------------
Reporter: weasel | Owner:
Type: defect | Status: new
Priority: High | Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor | Version: Tor: 0.2.8.6
Severity: Normal | Resolution:
Keywords: regression | Actual Points:
Parent ID: | Points: 2
Reviewer: | Sponsor:
--------------------------+------------------------------------
Comment (by teor):
Replying to [comment:10 arma]:
> Ok, I spent a while investigating this ticket yesterday. For context,
the Tor client on my travel laptop is still stuck in this bug, so I can
poke it in various ways to help debug if we think of useful ways. Here is
a checkpoint of my thinking process.
>
> There are two mysteries here:
>
> Mystery 1) Why does my Tor client not care to get any new directory
information?
>
> It's October 29 now, and my tor's datadirectory contains:
> {{{
> -rw------- 1 arma arma 1405537 Oct 21 12:14 cached-microdesc-consensus
> -rw------- 1 arma arma 3473955 Oct 21 12:43 cached-microdescs
> -rw------- 1 arma arma 0 Oct 21 12:43 cached-microdescs.new
> }}}
> After one of the clock jump events, my Tor tried to fetch a consensus
from a relay in the fallbackdir list, then it fell back to trying to fetch
a consensus from each of the directory authorities, and when one attempt
failed for each of those, it seems to have permanently given up -- and
that was days ago. I'm going to leave this mystery for later -- somebody
please feel free to pick it up in the meantime.
This sounds like an issue with the consensus download implementation. Here
are my questions:
* has your tor has marked each of the directory authorities down?
* has it marked all of the fallback directories down?
* has it exceeded the download schedule for downloading consensuses?
There are two kinds of download_status_t in 0.2.8, one retries on a
schedule regardless of success or failure, and the other retries on
failure. It seems there might be a problem with the first kind (which is
new in 0.2.8, and used to download the consensus).
I'd like to know what your consensus download_status_t has for all its
fields, particularly the attempt and failure counts. It may well have
exceeded the 255 failure count limit.
I also wonder how #8625 (commit 09a0f2d) affects this, but it is only in
0.2.9, and I'm not sure it would make it any better.
> Mystery 2) Why does my Tor client not recognize the new application
(socks) requests and jumpstart itself into trying to fetch new directory
stuff, make new circuits, and so on?
>
> My investigations led me to be suspicious of Tor commit {{{b1d56fc58}}}.
>
> Background: in the past a new socks request would come in, and
{{{connection_ap_handshake_rewrite_and_attach()}}} would get called on it,
which would call {{{connection_ap_handshake_attach_circuit()}}}, which
would call {{{circuit_get_open_circ_or_launch()}}}, and that function is
the one that does the "omg I don't have enough directory information and I
just got a socks request, I should reset everything so we can try again"
logic.
>
> But in commit {{{b1d56fc58}}}, we made
{{{connection_ap_handshake_rewrite_and_attach()}}} no longer attach it,
but rather it now calls {{{connection_ap_mark_as_pending_circuit()}}},
which effectively queues the stream for handling the next time the main
loop runs. That function adds the stream to the
{{{pending_entry_connections}}} smartlist, and sets
{{{untried_pending_connections}}} to 1, and returns.
>
> Then {{{run_main_loop_once()}}} calls
{{{connection_ap_attach_pending(0)}}}, which goes through and calls
{{{connection_ap_handshake_attach_circuit()}}} on each stream that needs
it.
>
> But when I gdb attach to my unhappy Tor client and set a breakpoint on
{{{connection_ap_attach_pending}}} and then do a new socks request, it
seems that it never calls the function!
>
> The earlier parts of {{{connection_ap_handshake_rewrite_and_attach()}}}
*are* being called, for example {{{rep_hist_note_used_port()}}} gets
called just fine. So I think the stream is being added to
{{{pending_entry_connections}}}, and then somehow things aren't working
after that.
This might be related to the above bug, or it might not be.
This code would need to reset the authority and fallback failures, and
also the download status for the consensus.
--
Ticket URL: <https://troodi.torproject.org/projects/tor/ticket/19969#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online