question

Ed Sutter ed.sutter at alcatel-lucent.com
Tue Apr 30 04:43:28 WST 2013


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
>



More information about the Dropbear mailing list