Re: Invalid channel numbers

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Peter Gutmann wrote:

> der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> writes:
>
>
> > > When you get a channel-specific request (channel open, channel
> > > request, etc), you're supposed to send back a succeeded or failed
> > > status.  How do you send back a response for the condition that you
> > > couldn't parse the request to the point of finding the channel number
> > > to use in the response?
> >
> > There is no such condition, because if you can't parse the request, you have
> > no request to respond to, so you don't have to worry about framing any
> > particular kind of response to it.
>
>
> Does the spec say this anywhere?  I can see an implementation hanging while
> waiting for a response to a request that'll never arrive if you don't send it
> back at least some sort of response.  Not replying seems somewhat broken to
> me, if the spec says (as it seems to) that you need to send back a "succeeded"
> or "failed" response then not sending back anything under some conditions
> seems wrong - you've detected an error, you should send back some indication
> of this.

From section 5.4:

     byte      SSH_MSG_CHANNEL_REQUEST
     uint32    recipient channel
     string    request type in US-ASCII characters only
     boolean   want reply
     ... type-specific data

   If want reply is FALSE, no response will be sent to the request.
   Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
   or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
   messages.  If the request is not recognized or is not supported for
   the channel, SSH_MSG_CHANNEL_FAILURE is returned.

The channel number is part of the packet that is predefined.
Therefore, you can always parse the channel number, and
send the response.

If 'want reply' is true, and you don't understand the request,
send failure.  If 'want reply' is false, don't send anything,
regardless of whether you understand the request.

This is the only way this can work (otherwise, it is not possible
to line up requests and responses.)  I'm also pretty sure we've
discussed it before in the working group, but I don't see in the
draft, that the responses must be made in order, in the case of
multiple requests.

I will admit, it would be nice if the final sentance was more
clear (or gone.)  If any change is needed, I would say something
like:

   If want reply is FALSE, no response will be sent to the request.
   Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
   or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
   messages.

   If the request is not recognized or is not supported for
   the channel, and 'want reply' is true, SSH_MSG_CHANNEL_FAILURE
   is returned.  If 'want reply' is false, the request is
   ignored.

   The client is allowed to send further messages without waiting for
   the response to the request.  Requests MUST be responded to in the
   order received.

   This message does not consume window space and can be sent even if no
   window space is available.  Request types are local to each channel
   type.

Thanks,

Joseph