dbclient and detecting broken connections

[Ahilan Anantha]

Hi Farrell,

That's an interesting idea. But like you said, if the server suddenly 
disappears off the network then the client won't be told to die if we do 
idle timeouts and/or keep alives. The server alive in OpenSSH is 
request/response so it ensures that the client can figure out the 
connection is hozed even if the server is frozen. Fortunately it doesn't 
look too hard to port over support from OpenSSH. I should hopefully have 
a messy patch today that I can tidy up.

Thanks,

Ahilan

Farrell Aultman wrote:
> Hello Ahilan,
> 
> Look at the Idletimeout option, "-I".  Try to run "-I" on the client.  
> To the best of my remembrance, you are correct, -K only sends keep alive 
> messages and doesn't actually check for any response.  Some type of keep 
> alive will have to be sent from the server side for this to work.  I 
> don't recall if there is a response to -K (when sending keep alives from 
> the client), so you may have to send keep alives from the server to the 
> clients.
> 
> What I do is run -I on the server and -K on the clients to detect when 
> clients have went down and shut down the server process, which causes 
> the client to die.  But if my server process died, I'd be screwed too.
> 
> Farrell 
> 
> On Tue, Dec 8, 2009 at 6:47 PM, Ahilan Anantha <aanantha at riverbed.com 
> <mailto:aanantha at riverbed.com>> wrote:
> 
>     Hi List,
> 
>     I plan to use "dbclient" as a low memory footprint alternative to
>     OpenSSH's "ssh" for SSH tunnels.
> 
>     On the client I have software that creates SSH tunnels to many
>     systems. Sometimes the connection to these remote systems will
>     break, at which point "ssh" will exit. The exit gets detected and
>     the connection gets reestablished. But this works in "ssh" because
>     I'm using the ServerAliveInterval and ServerAliveCountMax options.
>     Without them, ssh would never check that the connection was up and
>     I'd have to wait an eternity for a TCP timeout. Or implement my own
>     heartbeat on top of the tunnel.
> 
>     dbclient instead has a "-K" option. It's been suggested on this
>     mailing list that this basically did the same thing... but based on
>     my testing that doesn't appear to be true. At least for the case of
>     dbclient against an OpenSSH server.
> 
>     I ran "dbclient -K 3" against an OpenSSH server. Then I sent a
>     SIGSTOP to the sshd child process servicing the connection. dbclient
>     did not terminate the session within any reasonable amount of time.
>     Perhaps if I waited a really long time, I would see a TCP timeout.
> 
>     When I try the same with an "ssh -oServerAliveInterval=3
>     -oServerAliveCountMax=1", the ssh client disconnects very quickly:
> 
>     "Disconnecting: Timeout, server not responding."
> 
>     After comparing the OpenSSH and dropbear source code, it appears to
>     me that dropbear implements the equivalent of OpenSSH's "TCP keep
>     alive" but not "server alive".
> 
>     In the case of "server alive", OpenSSH requires a response from the
>     server. Each server alive interval it checks to see how many server
>     alive requests are outstanding. If that count exceeds the max
>     (default is 3), it terminates the connection. In the case of "TCP
>     keep alive", ssh sends a message with no response requested. In this
>     case, it's just trying to maintain some activity over the stream so
>     that intermediate firewalls don't kill it as an idle connection.
> 
>     Is this a known issue? Has anyone else asked for this?
> 
>     Regards,
> 
>     Ahilan
> 
>