Timeout dead connections

[Matt Johnston]

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

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
>>>>>>>>>
>>>>>>
>>