dbclient and detecting broken connections

[Farrell Aultman]

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>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091209/744c58a1/attachment.html