Re: Detect dropped connections
Matt Johnston matt at ucc.asn.au writes: 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 In the interests of learning more, under what circumstances would you _not_ want dropbear to exit when it couldn't make the connection? - Johan
Re: Detect dropped connections
On Thu, Jul 22, 2010 at 02:46:38PM +, Johan Ribenfors wrote: Matt Johnston matt at ucc.asn.au writes: 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. In the interests of learning more, under what circumstances would you _not_ want dropbear to exit when it couldn't make the connection? The kind of situation I had in mind is where you have a set of say 5 ports you want forwarded but one of the ports is already bound on the server (perhaps you've forwarded that separately?). I guess in automated circumstances with -N that isn't very common. It's more of an issue if you have some standard LocalForward per-host entries in a ~/.ssh/config for OpenSSH client, but don't care much if they don't always work. Cheers, Matt
Re: Detect dropped connections
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
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
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
