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 >
