question

[Ed Sutter]

Matt,
Well, I think I finally found the problem.  At least my testing (so far) 
says its fixed...
I see there is a "windowing" type of flow control between client and server.
This is where my error was.  Since, I don't use channelio(), I had to 
rewrite a lot of
the mechanisms that in a normal use of dropbear would "just work".
Anyway, I was decrementing the recvwindow value, but I was not doing 
anything
with it.  I noticed in channelio() that when recvwindow gets to a 
certain level it
sends a message to the client telling it to increase the window size.  
Since I wasn't
doing that, the client was essentially switched off waiting for the 
window resize
message to come in...
I now detect the recvwindow size getting low and call 
send_msg_channel_window_adjust()
to inform the client that the windowsize should be bumped up.
With that fixed, things are now running smoothly.
Does that make sense?
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