Subject: Re: [PATCH] Follow RFC4253 section 11.4

Re: [PATCH] Follow RFC4253 section 11.4

From: Steven Dake <>
Date: Fri, 02 Mar 2012 10:38:28 -0700

On 03/01/2012 02:39 PM, Peter Stuge wrote:
> Henrik Nordström wrote:
>> The SSH_MSG_UNIMPLEMENTED is in response to the packet with seqno 4
>> (fifth packet), which is the keep-alive sent before authentication.
>> Note that SSH_MSG_UNIMPLEMENTED should be sent in response to
>> unimplemented messages even if want_reply == 0. want_reply is a
>> message specific flag, not part of transport.
> I don't know. I think SSH_MSG_UNIMPLEMENTED would only be acceptable
> if the server does not implement SSH_MSG_GLOBAL_REQUEST at all.
> (It might not, it's only used for setup and cancelling of
> tcpip-forward.
> An easy way out for libssh2 could be to set want reply = 1 for

Note that I am not using keepalive with want reply set. Ie the code
does the following:
libssh2_keepalive_config(trans_ssh->session, 0, KEEPALIVE_TIMEOUT);

I made this change to stop getting the 82 packets which were causing the

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.

> keepalive and require either SSH_MSG_UNIMPLEMENTED,
> if the global request is sent after something else has been sent, but
> before response has been received, there is still a problem. This
> might already be managed within libssh2 though, that keepalives are
> never sent in the middle of another request.
> I don't think an SSH client can allow itself to send a global request
> with want reply = 0 if it is not already sure that the server
> supports that particular request, unless the client adds some
> elaborate buffering of global requests it has sent and tries to track
> which ones have been answered by the server. Not what we want.
> I think want reply = 1 for keepalive would be fine, and isolates the
> problem to that part of the code.
> //Peter
> _______________________________________________
> libssh2-devel

Received on 2012-03-02