[tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#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:
--------------------------+------------------------------------
Changes (by arma):

 * points:   => 2


Comment:

 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.

 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19969#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online