Hi, The keepalive option makes sure that traffic is transmitted every N seconds. It can be used to avoid routers closing idle (keeping them "alive").
If the connection is gone then the connection will be terminated after a timeout (a minute perhaps?) when the traffic is transmitted. A program doesn't get notified when a network interface goes down (at least with standard Unix programming interfaces), so it only finds out when traffic is sent. An alternative might be to "killall dropbear", "/etc/init.d/dropbear start" in /etc/ppp/ip-down.d or similar, since that part knows that the interface has gone away. Cheers, Matt On 3 February 2014 8:34:15 pm AWST, Alexander Kriegisch <[email protected]> wrote: >Hi Matt. > >Thanks for your swift reply. Could you please elaborate on what "-K" is >actually meant to do (what is kept alive and how?) and how it might >help me solve my problem? Documentation on Dropbear is sparse and I >fail to see the connection. > >Kind regards >-- >Alexander Kriegisch >http://scrum-master.de > > >Matt Johnston schrieb am 03.02.2014 13:02: > >> Running with -K 30 for keepalive might sort it out? >> >> >> On 3 February 2014 4:25:49 pm AWST, Alexander Kriegisch >> <[email protected]> wrote: >>>My setup: >>> - Server (DSL/WLAN router running Dropbear sshd v2012.55) >>> >>> $ uname -mrsp >>> Linux 2.6.19.2 mips unknown >>> >>> $ ps | grep dropbear | grep -v grep >>> 1673 root 1352 S dropbear -i -R -a >>> 14826 root 1396 S dropbear -i -R -a >>> >>> - Client >>> >>> OS: Windows XP Pro 64-bit >>> SSH Client: Bitvise >>> >>>As you can see, my Dropbear runs as root in inetd mode, permitting >root >>>logins (which is what I use) and accepting connections to forwarded >>>ports from other hosts. I need this because my connection basically >>>creates a few forward tunnels (client to server) to other machines >>>behind the router as well as backward tunnels (server to client) to a >>>few services on the client's network. So far, so good. >>> >>>The DSL router gets disconnected once every night, reconnects within >>>seconds and gets a new IP address, which is the usual thing in >Germany >>>for consumer-type ISP connections. What I expect to happen is that >the >>>dropbear process goes down, but in ca. 4 out of 7 days this does not >>>happen. The main symptom is that the auto-reconnect for the SSH >>>connection to the dynamic host name fails because ports on the router >>>cannot be bound because they are already in use. When I check with >>>netstat I can see that indeed all the listening ports for the reverse >>>tunnels are still in use by the old Dropbear process which has not >>>terminated. On a few days a week it works, but I do not know the >>>circumstances or race conditions which cause this behaviour. So what >I >>>end up doing most of the time is log on to the router without the >>>tunnels and kill the non-terminated Dropbear process blocking the >>>listening ports. A few seconds later, the full-blown SSH connection >>>with forward and reverse tunnels automatical >>> ly reconnects and everything is fine for another 24 hours. >>> >>>Now this obviously is ugly and unstable. Is there a way to make >>>Dropbear understand it should terminate when the DSL connection is >>>gone? Or is there at least a workaround by which I can check if the >SSH >>>process ist still alive? I thought that maybe I could try and connect >>>to one of the stale reverse tunnels (localhost:someport on the >router) >>>in order to see if it is still functional, then kill the process >>>otherwise, but I had difficulty doing so because a wget test does not >>>work (I only have Busybox wget which does not have a time-out >>>parameter). >>> >>>Please ask for more information if this was too unspecific.
