dbclient and detecting broken connections

[Ahilan Anantha]

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