<div dir="ltr">I guess that I made the patch specific to my use case. I have a collection of wireless embedded devices that are running dbclient. The are installed in trucks and move in and out of radio range and talk to a central server running dropbear server. I want to keep the connection alive when they are in radio range, and allow the dropbear server process to detect when they are out of range and exit. So, in my case, the clients all send keepalive packets and the server process stays up as long as it gets it.<br>
<br>I thought about modifying dropbear to have a compile time option that would allow reacting to only data packets. Would that be OK?<br><br>"Also the time should probably be a updated when sending<br>
data packets too?" probably, in my case, clients always initiate the communication. But, it could easily be changed to do this. <br><br><div class="gmail_quote">On Mon, Sep 22, 2008 at 11:11 AM, Matt Johnston <span dir="ltr"><<a href="mailto:matt@ucc.asn.au">matt@ucc.asn.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Fri, Sep 19, 2008 at 05:45:34PM -0400, Farrell Aultman wrote:<br>
> This adds a command line option for specifying an idle_timeout. The command<br>
> line is:<br>
> -I <secs>. If dropbear doesn't receive any data packets within <secs>, the<br>
> dropbear process<br>
> associated with that session will exit.<br>
<br>
</div>This patch looks good, though testing here it seems that<br>
OpenSSH's client will send keepalive message that thwart the<br>
timeout. What is your use case for this patch? Would updating<br>
the last_packet time only for DATA packets make more<br>
sense? Also the time should probably be a updated when sending<br>
data packets too?<br>
<font color="#888888"><br>
Matt<br>
<br>
</font></blockquote></div><br></div>