Re: exit-signal vs openssh

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> I'm seeing packets with payload (after the want-reply boolean) of 
>> 	00 00 00 01 00 00 00 00 00 00 00 00 00
>> which makes sense only if I read the signal as uint32 instead of
>> string.

> I'm not sure I can make sense of your example, but if I recall this
> issue correctly, an old format exit-signal message will end with

>   uint32   signal number
>   END-OF-MESSAGE

> while a new format message will end with

>   uint32   string length n
>   byte[n]  string data 
>   END-OF-MESSAGE

> (I've substituted the internal representation of the string type).

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

     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.

So interpreted according to this, what I saw is a signal name
consisting of a single NUL, a false core-dumped flag, an error-message
"", and the first three octets of the length of the language tag, with
the language tag's last length octet, and any content, missing.

I suppose I could simply try parsing it both ways and see which one
works, since, as you point out, the only way both come out to the same
length is an old-style 0 and a new-style "", both of which are bogus.
Or, given the use I expect to make of that information, I could just
use the new message, and if the peer generates an unparseable message,
mark it as being unable to send us that information.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B