IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: exit-signal vs openssh



der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> writes:

> Close, but it's not at the end of the message.  connect-18 describes
> the exit-signal message as

Ooops, sorry, I mixed up "signal" and "exit-signal".

>      byte      SSH_MSG_CHANNEL_REQUEST
>      uint32    recipient channel
>      string    "exit-signal"
>      boolean   FALSE
>      string    signal name without the "SIG" prefix.
>      boolean   core dumped
>      string    error message (ISO-10646 UTF-8)
>      string    language tag (as defined in [RFC3066])
> 
> where the FALSE is the usual channel-request want-reply boolean, and
> the example octet string I gave above is only the part after that.

Then it seems hairier to get right. Perhaps you could do it like this:

First check the length in the signal name field (which should be a
string, but might be a signal number instead). If it's zero, it
doesn't matter. If it's non-zero, check the first byte of the string.
If that byte is 0 or 1, then it's probably not a string, but a
boolean, so parse the message according to the old format. Otherwise,
it should be a string, so continue parsing according to the new
format.

That kludge should work except if you are talking to an implementation
that uses the new format, and it happens to use signal names that
start with the bytes 0 or 1. Not likely, since signal names should (or
must?) be ascii.

I just checked my implementation. It doesn't do any of these tricks.
If it sees the old format of this message, it will just treat it as
the protocol error it is, and disconnect.

/Niels



Home | Main Index | Thread Index | Old Index