<html><head></head><body>Hi,<br>
<br>
Running with -K 30 for keepalive might sort it out?<br>
<br>
Cheers,<br>
Matt<br><br><div class="gmail_quote">On 3 February 2014 4:25:49 pm AWST, Alexander Kriegisch <alexander@kriegisch.name> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">My setup:<br /> - Server (DSL/WLAN router running Dropbear sshd v2012.55)<br /><br /> $ uname -mrsp<br /> Linux <a href="http://2.6.19.2">2.6.19.2</a> mips unknown<br /><br /> $ ps | grep dropbear | grep -v grep<br /> 1673 root 1352 S dropbear -i -R -a<br /> 14826 root 1396 S dropbear -i -R -a<br /><br /> - Client<br /><br /> OS: Windows XP Pro 64-bit<br /> SSH Client: Bitvise<br /><br />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.<br /><br />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<br /> ly reconnects and everything is fine for another 24 hours.<br /><br />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).<br /><br />Please ask for more information if this was too unspecific.</pre></blockquote></div></body></html>