Matt,
My previously mentioned change didn't fix anything; but
I've stumbled onto something else...
When I send data (using my version of send_msg_channel_data()) I wasn't
decrementing
the channel->transwindow value by the number of bytes I was sending.
As a result, my channel->transwindow value just kept increasing (this
surely seems
like a bad thing!). Would that cause the connection to eventually just
lock up?
I added the code that decrements this by the number of bytes I send out,
and now
I see that the channel->transwindow value hovers around 14K.
Testing now...
Ed
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
