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.
I thought about modifying dropbear to have a compile time option that would allow reacting to only data packets. Would that be OK? "Also the time should probably be a updated when sending data packets too?" probably, in my case, clients always initiate the communication. But, it could easily be changed to do this. On Mon, Sep 22, 2008 at 11:11 AM, Matt Johnston <[EMAIL PROTECTED]> wrote: > On Fri, Sep 19, 2008 at 05:45:34PM -0400, Farrell Aultman wrote: > > This adds a command line option for specifying an idle_timeout. The > command > > line is: > > -I <secs>. If dropbear doesn't receive any data packets within <secs>, > the > > dropbear process > > associated with that session will exit. > > This patch looks good, though testing here it seems that > OpenSSH's client will send keepalive message that thwart the > timeout. What is your use case for this patch? Would updating > the last_packet time only for DATA packets make more > sense? Also the time should probably be a updated when sending > data packets too? > > Matt > >
