Server process not closed after disconnect, problems with reconnect

[Alexander Kriegisch]

Hi Matt.

I have tested "-K 30" for a few nights, and it does not work. Maybe there is something wrong with Dropbear v2012.55. Is there any concrete reason to believe that this might have improved in later versions? Theoretically I could build a new binary for my platform, but because I have a new computer I would have to set up a Linux partition of VM first, create a full cross-compile toolchain and rebuild the firmware for my router. For the time being I have installed a hook script which does "killall dropbear" whenever the machine reconnects, similar to what you have suggested. Because Dropbear runs in inetd mode here, I do not even need to restart it.

Regards
-- 
Alexander Kriegisch
http://scrum-master.de


Matt Johnston schrieb am 06.02.2014 00:29:

> 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.
> 
> 
> On 3 February 2014 8:34:15 pm AWST, Alexander Kriegisch
> <alexander at kriegisch.name> wrote:
>>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.
>>
>>
>>
>>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
>>> <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.