Ted Rathkopf <[EMAIL PROTECTED]> writes:
> Find out what "standard signals" ssh2 expects its raw signal numbers
> to correspond to, and use a translation table. Translate to these raw
> values before sending them over the wire, and translate from these raw
> values into names/local values when you receive them over the wire.
I'm afraid that the ssh2 implementation expects the signal numbers to
mach the *local* signal numbers on the machine it is compiled for.
Then there is no such thing as "ssh2 standard signals". (Note: I'm
guessing here, from the fact that the specification does not address
this at all. I'll much appreciate definite information on this).
Perhaps an example will make it clearer what I mean:
Say that I use ssh on my sparc-linux machine, to connect to a solaris
machine and start some process (I'm doing that right now, but with
ssh1). Say that process is killed be me or the superuser sending it
the SIGUSR1 signal. The sshd deamon will notice that the child died,
and that the fatal signal was number 16 (that is SIGUSR1 on solaris).
It sends this information across the net, and my client will tell me
that the remote process was killed by the SIGURG (signal number 16 on
sparc-linux, which is a little puzzling, as that signal is usually not
fatal).
(BTW, this example works fine with ssh1, I just tried it. But it's
years since I read the ssh1 spec, so don't know how it handles
signals. Perhaps it uses strsignal on the side generating the signal,
and send a text message over the line? Anyway, it prints
[nisse@puck nisse]$ ssh sandra.lysator.liu.se xlogo
User signal 1
Waiting for forwarded connections to terminate...
The following connections are open:
X11 connection from sandra.lysator.liu.se port 59645
when I kill the xlogo with kill -USR1).
Note that restricting the implementation to only POSIX-signals doesn't
help much: On one system, 16 is the POSIX signal SIGUSR1, on the
other it is SIGURG, a non-posix signal.
It seems that signals 1-15 mean the same things on most (but not all
systems); that is why the broken behaviour of sending local signal
numbers will work most of the time. And that's also why I can get some
compatibility with broken implementations for free, by choosing
"canonical" standard numbers that match most local numbers on many
systems.
/Niels M�ller
