question

[Matt Johnston]

Ah that explains it, it did sound like a problem in the
channel layer.

Cheers,
Matt

On Tue, Apr 30, 2013 at 10:41:24AM -0400, Ed Sutter wrote:
> 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
>