Keepalive timeout with dropbear client

[David Chapdelaine]

Hi everyone,

We have been using version 65 of Dropbear to maintain an ssh connection to a central server. It usually works fine, but when there is a network failure the Dropbear client waits until there is a tcp timeout before declaring that there was a keepalive timeout. So in practice even though we set the keepalive timeout as 30 seconds, dbclient doesn't exit before ~15 minutes which is when the tcp timeout is triggered.

By digging in dropbear's code I noticed that when running in client mode, the connection to the server is blocking whereas that connection is non blocking when running in server mode. I thus changed the connection to non blocking in client mode. To do this I changed the call to connect_remote line 75-76 of cli-main.c from

int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 0, &error);

to

int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 1, &error);

Initial tests are good so far and it addresses our issue, but I wanted to run this through you to get your insights on potential problems with this change. As far as you know, is there any side effect that we should be aware of? Was there a reason why the connection was blocking in client mode?

Thanks a lot for your inputs!

David Chapdelaine
Développeur logiciel | Software Developer
T|P: [phone] p.6595 | ***@genetec.com<mailto:***@genetec.com>

[cid:***@01D0F159.91250450]

Conçu pour évoluer | Built to evolve | www.genetec.com/dna<http://www.genetec.com/dna>
[cid:***@01CBEA2D.0B393EC0]<Loading Image...@01CBEA2D.0B393EC0]<http://www.linkedin.com/company/genetec/> [cid:***@01CBEA2D.0B393EC0] <http://www.twitter.com/_Genetec_> [cid:***@01CBEA2D.0B393EC0] <http://www.youtube.com/Genetec>

[Matt Johnston]

Hi David,

Dropbear since 2015.68 always sets the socket non-blocking [1], so I think that change should be safe on older versions. The only risk I can think of is if it gets in some state where it might spin with 100% CPU.

Cheers,
Matt

[1] https://secure.ucc.asn.au/hg/dropbear/annotate/10f198d4a308/common-session.c#l68

Post by David Chapdelaine
Hi everyone,
We have been using version 65 of Dropbear to maintain an ssh connection to a central server. It usually works fine, but when there is a network failure the Dropbear client waits until there is a tcp timeout before declaring that there was a keepalive timeout. So in practice even though we set the keepalive timeout as 30 seconds, dbclient doesn’t exit before ~15 minutes which is when the tcp timeout is triggered.
By digging in dropbear’s code I noticed that when running in client mode, the connection to the server is blocking whereas that connection is non blocking when running in server mode. I thus changed the connection to non blocking in client mode. To do this I changed the call to connect_remote line 75-76 of cli-main.c from
int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 0, &error);
to
int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 1, &error);
Initial tests are good so far and it addresses our issue, but I wanted to run this through you to get your insights on potential problems with this change. As far as you know, is there any side effect that we should be aware of? Was there a reason why the connection was blocking in client mode?
Thanks a lot for your inputs!
David Chapdelaine
Développeur logiciel | Software Developer
<image001.png>
Conçu pour évoluer | Built to evolve | www.genetec.com/dna <http://www.genetec.com/dna>
<image002.png> <Loading Image...> <http://www.linkedin.com/company/genetec/> <image004.png> <http://www.twitter.com/_Genetec_> <image005.png> <http://www.youtube.com/Genetec>

[David Chapdelaine]

Hi Matt,

Thanks for pointing out that this change was done in more recent versions. Updating to a more recent version should be possible for us.

Regards,
David

From: Matt Johnston [mailto:***@ucc.asn.au]
Sent: Tuesday, June 7, 2016 8:44 AM
To: David Chapdelaine <***@GENETEC.COM>
Cc: ***@ucc.asn.au
Subject: Re: Keepalive timeout with dropbear client

Hi David,

Dropbear since 2015.68 always sets the socket non-blocking [1], so I think that change should be safe on older versions. The only risk I can think of is if it gets in some state where it might spin with 100% CPU.

Cheers,
Matt

[1] https://secure.ucc.asn.au/hg/dropbear/annotate/10f198d4a308/common-session.c#l68


On Tue 7/6/2016, at 7:59 pm, David Chapdelaine <***@GENETEC.COM<mailto:***@genetec.com>> wrote:

Hi everyone,

We have been using version 65 of Dropbear to maintain an ssh connection to a central server. It usually works fine, but when there is a network failure the Dropbear client waits until there is a tcp timeout before declaring that there was a keepalive timeout. So in practice even though we set the keepalive timeout as 30 seconds, dbclient doesn’t exit before ~15 minutes which is when the tcp timeout is triggered.

By digging in dropbear’s code I noticed that when running in client mode, the connection to the server is blocking whereas that connection is non blocking when running in server mode. I thus changed the connection to non blocking in client mode. To do this I changed the call to connect_remote line 75-76 of cli-main.c from

int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 0, &error);

to


int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 1, &error);

Initial tests are good so far and it addresses our issue, but I wanted to run this through you to get your insights on potential problems with this change. As far as you know, is there any side effect that we should be aware of? Was there a reason why the connection was blocking in client mode?

Thanks a lot for your inputs!

David Chapdelaine
Développeur logiciel | Software Developer
T|P: [phone] p.6595 | ***@genetec.com<mailto:***@genetec.com>

<image001.png>

Conçu pour évoluer | Built to evolve | www.genetec.com/dna<http://www.genetec.com/dna>
<image002.png><http://www.facebook.com/Genetec>