Opened 9 years ago

Closed 8 years ago

Last modified 7 years ago

#3116 closed enhancement (implemented)

Notice how far our connections get; Report something useful about where they get stopped

Reported by: nickm Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I think that we should note how far we get in our SSL connection and renegotiation attempts, and when an OR connection fails before entering state OR_CONN_STATE_STATE, we should note its OR_CONN_STATE state and its SSL state. We should then track to see if there is a point in the handshake process where some or all of our connections are getting stopped, so as to better and more rapidly diagnose blocking events, network failures, broken SSL libraries, and wombats eating the ethernet cable.

We should do this separately for incoming and outgoing connections.

As a first cut, we can just track "how far have we gotten" on each connection either when we close it or when it is open, and note the maximum progress. We can probably make it smarter too.

Child Tickets

Change History (10)

comment:1 Changed 9 years ago by ioerror

Shall I use the loud_ssl_states branch as the basis for this bug?
https://gitweb.torproject.org/nickm/tor.git/shortlog/refs/heads/loud_ssl_states

comment:2 Changed 8 years ago by nickm

Hm. I started hacking on this, and found an interesting issue: The numerical order of states in OpenSSL doesn't match to their temporal order. So to get useful information here, we'll need to define the actual temporal order we expect.

comment:3 Changed 8 years ago by ioerror

Huh, really? That's funky.

I think what we want is a way to simply log each line for important SSL transition states as we call it from the Tor source. This will give us a pretty good idea about what is failing and when.

comment:4 in reply to:  3 Changed 8 years ago by nickm

Replying to ioerror:

Huh, really? That's funky.

I think what we want is a way to simply log each line for important SSL transition states as we call it from the Tor source. This will give us a pretty good idea about what is failing and when.

Sure, I agree that's a good start, but I think that we can do better. The point of this ticket is that I'd like Tor to report a useful diagnostic by default if, say, all of our connections are dying in renegotiation, and not wait around for the user to configure debugging and extract the logs and send them to us.

Here's an alternate option: instead of trying to answer "what's the farthest we've gotten" we could try to answer "where do connections get killed"? In other words, when a connection times out or gets closed before the OR handshake is done, we could remember that, and report the totals if a while passes without our being able to build circuits.

comment:5 Changed 8 years ago by nickm

I've started hacking up an implementation in branch "feature3116" in my public repository. It's not done yet. The remaining issues, from the commit message, are:

  • We need documentation
  • We need to actually call the code that reports the failure when we realize that we're having a hard time connecting out or making circuits.
  • We need to periodically clear out all this data -- perhaps, whenever we build a circuit successfully?
  • We'll eventually want to expose it to controllers, perhaps.

comment:6 Changed 8 years ago by nickm

arma suggests I should look at control_event_boootstrap_problem() as a place to call the 'report what's been happening' function.

comment:7 Changed 8 years ago by nickm

Status: newneeds_review

Okay, the "feature3116" branch in my public repository is I think ready for review.

comment:8 Changed 8 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Two weeks without comment. I've taken another careful look at the code, added a memory-saving tweak, and merged it.

comment:9 Changed 7 years ago by nickm

Keywords: tor-client added

comment:10 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.