Timeout dead connections

Matt Johnston matt at ucc.asn.au
Fri Apr 5 19:18:26 WST 2013


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.

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



More information about the Dropbear mailing list