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
