[tor-bugs] #3769 [Tor Relay]: Bufferevent-based server sometimes succeeds, sometimes fails.

[Tor Bug Tracker & Wiki]

#3769: Bufferevent-based server sometimes succeeds, sometimes fails.
-----------------------+----------------------------------------------------
 Reporter:  nickm      |          Owner:                    
     Type:  defect     |         Status:  new               
 Priority:  major      |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Relay  |        Version:                    
 Keywords:             |         Parent:  #3561             
   Points:             |   Actualpoints:                    
-----------------------+----------------------------------------------------

Comment(by Sebastian):

 Running fluxe3 with bufferevents now (no filtering bufferevents yet):

 ~/build/libevent$ git rev-parse HEAD
 2cbe115cbcdd47d954fa47a96c206c5c6ee63ddc

 ~/build/tor$ git rev-parse HEAD
 b161674d5dc312f95a495bed3c25d892fc9f0550

 The situation looks very much improved, no more reports about failing to
 open circuits (the circuit build timeout also doesn't rise anymore).

 I did see another few of these tho: [warn] TLS error while handshaking
 (with bufferevent) with [scrubbed]: ssl handshake failure (in SSL
 routines:SSL3_READ_BYTES:SSL3_ST_SR_CERT_A)


 When connecting to it as a client, i get this:

 {{{
 $ src/or/tor --usebridges 1 --bridge 78.47.18.110:80
 [notice] Tor v0.2.3.2-alpha-dev (git-b161674d5dc312f9). This is
 experimental software. Do not rely on it for strong anonymity. (Running on
 Darwin x86_64)
 ...
 [notice] Bootstrapped 10%: Finishing handshake with directory server.
 [notice] Learned fingerprint ED13D1D13C1E57C6A406DD64551D2F905AB99AFF for
 bridge 78.47.18.110:80
 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
 [notice] Bootstrapped 50%: Loading relay descriptors.
 [notice] new bridge descriptor 'fluxe3' (fresh)
 [notice] I learned some more directory information, but not enough to
 build a circuit: We have no usable consensus.
 [warn] Received http status code 404 ("Not found") from server
 '78.47.18.110:80' while fetching consensus directory.
 [warn] Received http status code 404 ("Not found") from server
 '78.47.18.110:80' while fetching consensus directory.
 }}}

 and sure enough - there isn't a cached-microdesc-consensus file in
 fluxe3's datadir. Only 20 minutes after starting up did it decide to fetch
 a microdesc-consensus and store it in its datadir. A client that connets
 through it (again via the bridges line from above) successfully
 bootstraps. While it does so, the relay logs (5 times in total):

 {{{
 [warn] Bug: Duplicate call to connection_mark_for_close at
 directory.c:3549 (first at directory.c:3549)
 }}}

 This COULD be a coincidence as it is a public relay, but it happened right
 in the second where the client fetched descriptors, and it happened again
 when I re-started my client without cached dir info. Restarting it with
 cached dir info doesn't cause problems.

 Another thing that is curious is that it takes the client a full minute to
 go do this step:
 {{{

 Aug 25 07:55:38.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Aug 25 07:56:39.000 [notice] We're missing a certificate from authority
 with signing key 3509BA5A624403A905C74DA5C8A0CEC9E0D3AF86: launching
 request.
 }}}

 This is reproducible. After all this, using the tor client for basic
 browsing works.

 The client is not using bufferevents in these tests. I'm keeping the relay
 up on bufferevents for now, please run tests as you see fit.

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