Server process not closed after disconnect, problems with reconnect

Matt Johnston matt at ucc.asn.au
Mon Feb 3 20:02:46 WST 2014


Hi,

Running with -K 30 for keepalive might sort it out?

Cheers,
Matt

On 3 February 2014 4:25:49 pm AWST, Alexander Kriegisch <alexander at kriegisch.name> 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.
>-- 
>Alexander Kriegisch
>http://scrum-master.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20140203/af32972d/attachment.htm 


More information about the Dropbear mailing list