Re: Detect dropped connections

2010-07-21 Thread Matt Johnston
Hi,

Apologies to everyone for the long delay in replying.

On Wed, Jul 07, 2010 at 10:42:11AM +0100, Dan O'Donovan wrote:
 You're correct that the -K option should prevent the server and the routers
 in between from closing the connection.
 I tried using the -I option in the same way that you did but it didn't work
 for me.  I suspect that the keep-alives sent with the -K actually prevent
 the link from ever appearing as idle, although I'm not entirely sure.

This does seem to be the case - I'll look at fixing it.
 
 We decided to use 'autossh' to launch 'dbclient' and monitor the connection
 by sending its own link test messages.  See:
 http://www.harding.motd.ca/autossh/
 That works well for us.  However, we still had one issue.  If dbclient
 failed to set up the reverse tcp forward, it wouldn't exit with an error so
 autossh would never know.
 So I made the following minor code change (perhaps this could be considered
 for a future release of dropbear?):

This looks sensible (exiting if a -R forward fails when -N
is specified). I wonder if anyone would have problems if
they're using -N and multiple -L/-R options and don't mind
of only some of them fail - maybe it should be a separate
commandline flag.

Cheers,
Matt


Re: Detect dropped connections

2010-07-21 Thread Matt Johnston
On Wed, Jul 21, 2010 at 01:47:10PM +, Johan Ribenfors wrote:
 This compiled and ran fine - but didn't solve the problem.  The server 
 (OpenSSH) would still drop the occasional connection and dropbear wouldn't 
 notice.  I might be using it incorrectly, (I hope I am) but don't think so. 
 Just to make it difficult, when testing dropping the connection on the server 
 - 
 with -A or -I - dropbear _always_ notices.

Have you set any ClientAliveInterval or TCPKeepAlive options
on the server? I wonder if the server sometimes might not
have noticed that the  client connection has gone away so
will keep the listening port in use, so even reconnecting
won't help as it won't be able to bind to that port. I may
be misunderstanding some of the problem though.

Cheers,
Matt


Re: Detect dropped connections

2010-07-21 Thread Johan Ribenfors
Matt Johnston matt at ucc.asn.au writes:

 
 On Wed, Jul 21, 2010 at 01:47:10PM +, Johan Ribenfors wrote:
  This compiled and ran fine - but didn't solve the problem.  The server 
  (OpenSSH) would still drop the occasional connection and dropbear wouldn't 
  notice.  I might be using it incorrectly, (I hope I am) but don't think so. 
  Just to make it difficult, when testing dropping the connection on the 
server - 
  with -A or -I - dropbear _always_ notices.
 
 Have you set any ClientAliveInterval or TCPKeepAlive options
 on the server? I wonder if the server sometimes might not
 have noticed that the  client connection has gone away so
 will keep the listening port in use, so even reconnecting
 won't help as it won't be able to bind to that port. I may
 be misunderstanding some of the problem though.
 
 Cheers,
 Matt
 
 

Matt,

They are both set:

KeepAlive yes
ClientAliveInterval 60

You have the problem backwards though - the server connection has gone away, 
and the client hasn't noticed.

- Johan