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