Timeout dead connections

Fabrizio Bertocci fabriziobertocci at gmail.com
Wed Mar 27 23:41:40 WST 2013

I remember reporting this problem and sending a patch long time ago (for
version 0.52).

The problem with the keep-alive (if I remember correctly) was that every
time dropbear was sending the keep-alive message, it was also resetting the
timeout counter... so dropbear or dbclient never detect the dropped
Here is an extract from my old email sent on 9/29/2010:

Hope this help,


First Issue: When keep-alive messages are sent, they reset the idle timeout
counter. (-I counter).
I would expect that SENT messages (in particular keep-alive packets) do not
affect the idle timeout...
This is in function write_packet() (file packet.c)
When a message is written, it stores the current time in both the registers
for the last packet transmitted *AND* last packet (for the idle timeout):
        ses.last_trx_packet_time = time(NULL);
        ses.last_packet_time = time(NULL);

(beside that, this cause two system calls, to read the time, when only one
would be needed... just optimizing :) )
This is a little unexpected because I would think that the idle timeout
works only on received packets, not about sent packets.
Basically if I start dropbear with -I and -K options, the idle timeout will
never kick in... because the keepalive will always reset the timer even if
the connection is dead.

I'm proposing to simply remove the line:
        ses.last_packet_time = time(NULL);
So the idle timeout does not get reset when any packet is sent.

Watch out: after this change, the semantic of the argument -I is different
than before, as it only consider received packets... but at least it makes
more sense.
Here is a scenario WITHOUT this modification:
1. Start the server with: dropbear -K 15 -I 20  [...]
2. Start the client with dbclient -K 15 [...]
3. On my device, start a program that sends data over one tunneled port
Everything works fine, connection is up and data is exchanging.
4. Unplug my embedded device (the one running dbclient)
-> The server does not detect the connection is down. Any attempt to access
a tunneled port cause the caller to hang.

now, after this change, with the same scenario, after I unplug my box, the
server detects it after 20 seconds and closes the connection.

Second Issue: When a keepalive message is received, the idle timeout timer
(for received packets) is NOT updated.
I'm referring here to the function 'process_packet()' in file
Here the timer update:
    ses.last_packet_time = time(NULL);
is performed AFTER the first switch where we check for SSH_MSG_IGNORE,
So, in few words: although a keep-alive message (that is a message of type
SSH_MSG_IGNORE) is correctly ignored, but the timer is not reset.

Here is what happen:
1. Start my server again with dropbear -I 20 [...]
2. Start my client with dropbear -K 15 [...]
(this time I'm not starting my application to send data over a tunneled

Without doing anything, the server will close the connection after 20
seconds. No matter if the client have sent the keep-alivemessages...

After moving that statement:
    ses.last_packet_time = time(NULL);
BEFORE the first switch(), now a keep-alive message cause the idle timer to
reset, and the previous test case works as expected (server does't

So, in conclusion, as you see, these two small changes are critical for my
situation, and I believe they could also benefit others with similar needs.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130327/c9d21de1/attachment.htm 

More information about the Dropbear mailing list