[tor-bugs] #7157 [Tor]: "Low circuit success rate %u/%u for guard %s=%s."

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Dec 18 23:40:21 UTC 2012


#7157: "Low circuit success rate %u/%u for guard %s=%s."
-----------------------------------------+----------------------------------
 Reporter:  arma                         |          Owner:                    
     Type:  enhancement                  |         Status:  needs_revision    
 Priority:  normal                       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                          |        Version:                    
 Keywords:  tor-client, MikePerry201212  |         Parent:  #5456             
   Points:                               |   Actualpoints:  19                
-----------------------------------------+----------------------------------

Comment(by mikeperry):

 Replying to [comment:26 nickm]:
 > Replying to [comment:25 mikeperry]:
 > > I did not do anything with timestamp_dirty yet. I'm pretty sure we
 want to keep at least the hidserv timestamp_dirty additions.. Do you just
 want me to move the timestamp_dirty change to the cannibalization code? It
 does appear like that might make us decide against re-cannibalizing it,
 and may impact our use of cannibalized circuits under predictive building
 conditions + new identity.. hrmm...
 >
 > At this point, I think whichever option is simplest would be best here.
 This is tricky stuff, and at least your existing code is tested... but if
 it breaks functionality we care about, we need to think of the simplest
 fix there. Regressions are teh suxx0r.
 >
 > > If you want me to switch to another path_state_t flag, I can do that,
 but it's a bit more changes+refactoring.

 I do like the idea of having symmetry in the path_state_t transitions..
 Right now we have BUILD_ATTEMPTED, BUILD_SUCCEEDED, and USE_SUCCEEDED, but
 no USE_ATTEMPTED. USE_ATTEMPTED would allow us to stop abusing
 timestamp_dirty as part of our path_state_t state machine, and *might*
 stave off future bugs due to additional future use of timestamp_dirty..

 If you're willing to hold off on merging this to review #7341 and #7691,
 it probably makes sense to make this change now. That way, I can retest
 all three bugs with the same tests once I fix any changes you want me to
 make to those two bugs (and I'm sure there will be at least a few).

 Or, we can file a separate ticket for this path_state_t change, and do the
 retesting for it and those two after you review them.

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


More information about the tor-bugs mailing list