Timeout dead connections

[Mattias Walström]

Actually.. when I looked at it again. My first session has been closed, it took some while, but at last it seems like it was closed.

I just read more about TCP timeouts, must have mixed things up. It is rather long, but it seems that dropbear now clean upp after itself.

Now in who, I can see that my first entry (made Apr  5 07:24:09) is now removed.
admin           pts/0           00:00   Apr  5 15:56:06  y.y.y.y
admin           pts/1           05:39   Apr  5 09:39:05  y.y.y.y
admin           pts/2           03:05   Apr  5 12:52:47  y.y.y.y

Mattias
On 2013-04-05 15:52, Mattias Walström wrote:
> I am not using Keepalive. Why is keepalive required? If reading the manual understood that was to make sure firewalls did not close the connection.
>
> Shouldn't a TCP socket timeout in maximum 15 minutes by itself?
>
> Mattias
>
>
> On 2013-04-05 13:18, Matt Johnston wrote:
>> 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
>>>>>>>>>
>>>>>>
>>
>