Timeout dead connections

[Roy Tam]

2013/4/5 Matt Johnston <matt at ucc.asn.au>:
> Are you using -K ? I wouldn't expect it to time out otherwise. As an example
> I hibernate my computer nightly but connections remain alive in the morning.

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.

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