Subject: Re: [PATCH] Follow RFC4253 section 11.4

Re: [PATCH] Follow RFC4253 section 11.4

From: Steven Dake <>
Date: Mon, 05 Mar 2012 18:49:05 -0700

On 03/05/2012 12:02 PM, Daniel Stenberg wrote:
> On Fri, 2 Mar 2012, Steven Dake wrote:
>> I made this change to stop getting the 82 packets which were causing
>> the leaks.
>> I am not in favor of asserting the lib when packet 3 is received.
>> There are probably many conditions under which the error packet 3
>> could be received with different ssh daemons (I am using openssh for
>> the server atm). I'd prefer it be rejected silently (or given back to
>> the api caller) over an assertion.
> Hey!
> I've not really caught up the backs and forths of this discussion. Is
> there an outcome or patch suggested or where do we stand on the leak thing?

Packet type MSG_UNIMPLEMENTED will be leaked if a keepalive_config is
sent before authorization is done (My code was doing this previously as
I thought keepalive should be done immediately after opening the session).

Packet type MSG_REQUEST_FAILURE will be leaked every time a keepalive is
sent when the keepalive_config was set with want_reply (2nd parameter)
set to 1. This was the cause of the massive leaking that occurred. I
just set that second parameter to 0 and there are no more leaks.

Neither of these message types is handled appropriately, so they will
always be leaked.

I think there was some discussion about keeping track of
request/response packets to map unimplemented and request failure
responses back to the requesting API. I have no suggestions on that
point, but there were some other discussions in the thread if your

Received on 2012-03-06