[tor-bugs] #3443 [Tor]: Client with low CBT can't establish any circuits

[Tor Bug Tracker & Wiki]

#3443: Client with low CBT can't establish any circuits
---------------------------------------------------+------------------------
 Reporter:  arma                                   |          Owner:                    
     Type:  defect                                 |         Status:  needs_review      
 Priority:  major                                  |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                                    |        Version:                    
 Keywords:  regression tor-client MikePerry201211  |         Parent:                    
   Points:                                         |   Actualpoints:  8                 
---------------------------------------------------+------------------------

Comment(by nickm):

 Replying to [comment:46 mikeperry]:
 > Replying to [comment:45 nickm]:
 > > Dumb question:
 > >
 > > * I can't see what actually relaxes the timeout when relaxed_timeout
 is set.  It appears that the first time through the
 circuit_expire_building loop, we set relaxed_timeout , but the next time
 through the loop, we'll see that relaxed_timeout is already set, and call
 the "No circuits are opened" log message", and go on.  What's supposed to
 be happening here?  I thought the logic was that a relaxed_timeout circuit
 should get a more lax timeout, but it seems like everybody's getting the
 same close_cutoff.
 >
 > The logic is "If there are no opened circuits, allow *every* circuit to
 wait until the close_cutoff, but mark each one that we decide to do this
 for, so we can both avoid using them later unless we have to, and also do
 some CBT bookkeeping. As soon as there are *any* opened circuits, we can
 stop doing this relaxed timeout stuff and even let all the unbuilt relaxed
 circuits we were waiting on expire immediately."

 I'm really confused here; I don't see how the code is doing that.  In
 particular, I'm looking at the part that starts "if
 (!any_opened_circuits)."  I'll read it again until it makes sense once I'm
 back online later.

 > However, I've decided to change the "any_opened_circuits" check to be
 "Are there any opened 3 hop circuits that we're not trying to
 cannibalize?" Otherwise, I think we're going to count open 1-hop and other
 weird circuits to mean we shouldn't relax, which is not quite right.

 seems sensible.


 > > Other than that, if it's testing ok, I say it's mergeable.
 >
 > Should I squash it down? Should this all be just one commit?

 No; I'll do squashing as needed before I merge.

 > As a heads up, I also plan to rebase my other two branches (#7157 and
 #7341) to be on top of this one, to make testing all of them easier (since
 all three can be exercised with the same test).

 Okay, but if this one gets squashed before merge, you'll need to rebase
 them back onto master.

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