[tor-bugs] #6341 [Tor Relay]: connection_or_flush_from_first_active_circuit() does wrong thing when ewma_enabled

[Tor Bug Tracker & Wiki]

#6341: connection_or_flush_from_first_active_circuit() does wrong thing when
ewma_enabled
-----------------------+----------------------------------------------------
 Reporter:  arma       |          Owner:                    
     Type:  defect     |         Status:  needs_review      
 Priority:  normal     |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Relay  |        Version:                    
 Keywords:             |         Parent:                    
   Points:             |   Actualpoints:                    
-----------------------+----------------------------------------------------

Comment(by robgjansen):

 Replying to [comment:37 arma]:
 > As usual, it would be great if you could get me info-level logs from one
 of these clients that doesn't bootstrap, and ideally from a directory
 mirror that doesn't bootstrap too.
 >

 Right on:
 [https://trac.torproject.org/projects/tor/attachment/ticket/6341/nonexit11.log.xz
 relay log here],
 [https://trac.torproject.org/projects/tor/attachment/ticket/6341/webclient5.log.xz
 client log here].

 A note on the log format: the first column is the real (wall clock) time,
 and the third column is the virtual time (returned with any time() type
 functions) as hours:minutes:seconds:nanoseconds.

 The relay starts at just over the 1 virtual-minute mark and finally
 reaches 100% at just under 28 minutes. The client starts at the 15
 virtual-minute mark and reaches 100% at just over 37 minutes. After
 reaching 100%, the client sees no additional socks connection errors.

 > I just used nickm's chutney tool to launch a self-contained tor network,
 and for the first 5 minute period, all the clients were getting 404's in
 response to their consensus fetches. After about 15 minutes though,
 everything had settled down and they all worked nicely. I wonder what is
 different in your situation.

 Me too. I ran a third experiment using 'FetchDirInfoEarly 1' and
 'FetchDirInfoExtraEarly 1' for the relays, and 'FetchDirInfoEarly 1' for
 the clients. There were no 404s for any of the nodes after the 5 virtual-
 minute mark.

 I'm still seeing a few socks errors though.

 For
 [https://trac.torproject.org/projects/tor/attachment/ticket/6341/webclient71.log.xz
 webclient71 in this log file], the client started up at the 15 minute 7
 seconds mark, and was bootstrapped to 100% 24 seconds later. The
 'FG_ERR_SOCKSCONN' occurs at minute 43. It appears the circuit building
 process may have been legitimately slow in this case because of exit8.
 Perhaps increasing the SocksTimeout to 3 minutes could help in this case.

 For
 [https://trac.torproject.org/projects/tor/attachment/ticket/6341/webclient74.log.xz
 webclient74 in this log file], the client didn't bootstrap 100% until
 almost 36 minutes. There were 3 'FG_ERR_SOCKSCONN' errors before that, but
 none after. The client again appeared to be attempting to download
 descriptors.

 Does any of this enlighten the problem? I'm curious if you can capture
 something from the logs that I didn't notice.

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