Timeout dead connections

[Roy Tam]

2013/4/5 Matt Johnston <matt at ucc.asn.au>:
>
>
> Roy Tam <roytam at gmail.com> wrote:
>>I got same issue with 2012.55-1.3 at debian(debian does not have 2013.56
>>at the moment) without -K switch.
>>Once I not issuing 'exit' command but closing putty window directly,
>>the session leaves alone.
>
> That sounds exactly like the situation fixed in 2013.56

I tried "dpkg-buildpackage -rfakeroot" dropbear-2013.56 and installed
dropbear_2013.56-0.1_i386.deb restarted dropbear services, open 2
putty connection to that host, and press [X] button on one of them,
then run "w" on another one, it show 2 sessions.
In "ps auxww", it shows 3 lines of:
/usr/sbin/dropbear -d /etc/dropbear/dropbear_dss_host_key -r
/etc/dropbear/dropbear_rsa_host_key -p 22 -W 65536

So, the problem still exists.

>
> Cheers,
> Matt
>>
>>>
>>> Cheers,
>>> Matt
>>>
>>>
>>> On 2013-04-05 16:25, Mattias Walström wrote:
>>>>
>>>> Hi!
>>>> I still have problems, this is my output from 'who':
>>>> admin           pts/0           02:50   Apr  5 07:24:09  x.x.x.x
>>>> admin           pts/1           00:00   Apr  5 09:39:05  y.y.y.y
>>>>
>>>> current time:
>>>> Fri Apr  5 10:18:27 CEST 2013
>>>>
>>>> shouldn't the first session be timed out? It has not just been idle
>>>> for 2 h 50 min,
>>>> the computer is not there any more. So in my opinion, dropbear
>>should
>>>> have forgotten the
>>>> connection.
>>>>
>>>> Mattias
>>>>
>>>> On 2013-04-01 17:01, Matt Johnston wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> The attached attached patch against 2013.56 should fix it, or
>>>>> https://secure.ucc.asn.au/hg/dropbear/rev/70811267715c
>>>>>
>>>>> Dropbear wasn't running cleanup handlers when it exited due
>>>>> to the TCP connection being closed.
>>>>>
>>>>> Matt
>>>>>
>>>>> On Thu, Mar 28, 2013 at 07:24:55PM +0800, Matt Johnston wrote:
>>>>>>
>>>>>> I think that -K on the server should be enough. On the
>>>>>> server can you run "tcpdump -i eth0 -w cap1.cap port 22",
>>>>>> get a ssh session going, pull out the cable, wait 10
>>>>>> minutes, then send me the capture?
>>>>>>
>>>>>> Could you also check that the Dropbear process for the
>>>>>> connection is still running after the connection should have
>>>>>> been finished. It's possible that the process is exiting but
>>>>>> the session cleanup code isn't working correctly. The whole
>>>>>> debug log might give me an idea what's going on.
>>>>>>
>>>>>> Cheers,
>>>>>> Matt
>>>>>>
>>>>>> On Thu, Mar 28, 2013 at 09:56:02AM +0100, Mattias Walström wrote:
>>>>>>>
>>>>>>> Thanks for your responses, all your suggestions imply that you
>>should
>>>>>>> do something
>>>>>>> in the client (set keepalive on client end), but shouldn't the
>>server
>>>>>>> itself be able to
>>>>>>> decide if a client is dead (can't OpenSSH do this?).
>>>>>>>
>>>>>>> If I do the -K 15 -I 20 on the server end only, this will close
>>the
>>>>>>> connection when
>>>>>>> the OpenSSH client has not sent any characters in 20s. I expected
>>the
>>>>>>> keepalive to be
>>>>>>> two way, that the server got responses on these packages as well,
>>is
>>>>>>> that not the case?
>>>>>>>
>>>>>>> Regards
>>>>>>>   Mattias
>>>>>>
>>>>>>
>>>>>>>>> On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström <
>>>>>>>>> mattias.walstrom at westermo.se> wrote:
>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>> I am running dropbear 2013.56, connecting to the server with a
>>PC
>>>>>>>>>> but
>>>>>>>>>> not performing a clean close (I pulled my ethernet cable),
>>this
>>>>>>>>>> caused
>>>>>>>>>> dropbear to never drop its connection.
>>>>>>>>>>
>>>>>>>>>> Looking at the utmp entries, I could see that the connection
>>never
>>>>>>>>>> got
>>>>>>>>>> dropped,
>>>>>>>>>> the utmp entries was kept forever, and running with debug
>>indicates
>>>>>>>>>> that
>>>>>>>>>> also.
>>>>>>>>>>   Tried to use -K to send keepalive, but it just keeps sending
>>>>>>>>>> keepalives
>>>>>>>>>> to the peer,
>>>>>>>>>> even it is no longer there, and not possible to reach.
>>Shouldn't
>>>>>>>>>> the connection be dropped if the keepalive does not reach its
>>>>>>>>>> destination?
>>>>>>>>>>
>>>>>>>>>> I know there is the -I option, but that does not really do
>>what I
>>>>>>>>>> want,
>>>>>>>>>> I want the connection to be tear down when the peer is
>>unreachable,
>>>>>>>>>> not
>>>>>>>>>> when the user has been idle for a while.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>   Mattias
>>>>>>>>>>
>>>>>>>
>>>
>