question

[Ed Sutter]

Hmmm...
Matt, I think this gives me a good hint as to where the problem is...
I have a function that is called by my application when asynchronous 
data is destined
for the SSH connection.  Am I correct to assume that this function 
should block
if ses.dataallowed is zero?  I added that check to my code, and I'm 
testing now..
Ed

> As long as you respond to a key exchange request from a
> client then it should keep working fine. Dropbear does that
> (common-kex.c) so unless you've patched it out it should be OK.
> Some clients (PuTTY?) send a rekey request every hour.
> Dropbear itself tries to rekey every 8 hours or 1GB data.
>
> Keepalive is usually implemented by sending SSH_MSG_IGNORE,
> but there isn't any requirement for that.
>
> It hasn't hit some edge case of the circular buffer in
> the channel handling code has it?
>
> Cheers,
> Matt
>
> On Thu, Apr 25, 2013 at 04:23:49PM -0400, Ed Sutter wrote:
>> Hi,
>> I noticed that I'm not doing any re-keying...
>> Will this cause a typical SSH client to quit?
>> Ed
>>> Hi,
>>> I have a modified version of the dropbear ssh server running in
>>> a multitasking RTOS environment that is not POSIX compliant.
>>> In almost all cases it is running perfectly...
>>> I run load tests on it by just using a simple expect script
>>> that spawns an ssh client and sends commands and expects
>>> responses (in a loop).
>>> If, within that loop, I occasionally (every ~30 minutes)
>>> disconnect and reconnect then I can let that run *forever*
>>> (haven't fully tested that).  :-(
>>>
>>> The problem I run into is if I just make an initial connection
>>> and put the script in a loop that simply keeps issuing commands
>>> and responses (I never disconnect; just maintain the initial session).
>>> After some unpredictable amount of time (usually it takes an hour or
>>> more); having invoked a few thousand commands, suddenly everything
>>> just stops.  The server is sitting in the select of the session_loop,
>>> and the client (in the expect script) is just waiting for a response.
>>>
>>> It seems like everything is where its supposed to be, but the client
>>> is not able to send any characters to the server.  It appears that the
>>> connection dropped; however, I'm fairly certain that it has not.
>>>
>>> So, I apparently broke something; hence my question...
>>>
>>> After the client/server transactions for key exchange,
>>> login/password etc..
>>> are complete and basically both sides are just passing encrypted
>>> data back
>>> and forth, is there any other periodic responsibility (on the
>>> servers' part)
>>> to issue any "keep-alive" type of commands (or something similar) that I
>>> have not implemented?
>>>
>>> Thanks,
>>> Ed