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.
