Re: USB-serial adapter suggestions needed

On Jan 12, 2024, at 08:27, bob prohaska <fbsd@www.zefox.net> wrote:

> On Thu, Jan 11, 2024 at 02:51:47PM -0800, Mark Millard wrote:
>>>>> 
>>>>> But there is no information here about which of those was the
>>>>> one to start the failure on nemesis.zefox.com :
>>>>> 
>>>>> A) Was it the tip process?
>>>>> B) Was it the shell process?
>>>>> C) Was it the nemesis.zefox.com side of the ssh?
> 
> It turns out that killing tip (using killall on the
> terminal server) does not disturb the ssh session.

DESCRIPTION
     The killall utility kills processes selected by name, as opposed to the
     selection by PID as done by kill(1).  By default, it will send a TERM
     signal to all processes with a real UID identical to the caller of
     killall that match the name procname.  The super-user is allowed to kill
     any process.
. . .
     -SIGNAL        Send a different signal instead of the default TERM.  The
                    signal may be specified either as a name (with or without
                    a leading “SIG”), or numerically.

Which SIGNAL values did you try? Did you try -SIGHUP ? There are
a bunch of signals that terminate the process(es) involved. The
handling of each can be distinct: separate signal handlers are
possible.

From man signal:

     Num   Name             Default Action       Description
     1     SIGHUP           terminate process    terminal line hangup
     2     SIGINT           terminate process    interrupt program
. . .
     9     SIGKILL          terminate process    kill program
. . .
     13    SIGPIPE          terminate process    write on a pipe with no
                                                 reader
     14    SIGALRM          terminate process    real-time timer expired
     15    SIGTERM          terminate process    software termination signal
. . .
     24    SIGXCPU          terminate process    cpu time limit exceeded (see
                                                 setrlimit(2))
     25    SIGXFSZ          terminate process    file size limit exceeded (see
                                                 setrlimit(2))
     26    SIGVTALRM        terminate process    virtual time alarm (see
                                                 setitimer(2))
     27    SIGPROF          terminate process    profiling timer alarm (see
                                                 setitimer(2))
. . .
     30    SIGUSR1          terminate process    User defined signal 1
     31    SIGUSR2          terminate process    User defined signal 2
     32    SIGTHR           terminate process    thread interrupt
     33    SIGLIBRT         terminate process    real-time library interrupt

If you did not specify the signal explicitly, you tried:

     15    SIGTERM          terminate process    software termination signal

(I'm not claiming all those "terminate process" signals are
likely to be involved. But SIGTERM is need not be involved
at all.)

> Both the ssh connection from workstation to terminal
> server and the su to root needed to run tip survive.
> 
> I should apologize for not testing this sooner, it
> was a very easy experiment. If you think of useful
> variations please indicate them.

See above, in particular SIGHUP .

> The "invalid characters in banner" message still
> intrigue me. Might it be possible for output from
> tip to ssh inadvertently contain a ~. sequence in a
> direction that makes ssh or sshd disconnect?

I doubt ssh can be confused about where characters
are coming from.

> It does appear that what looks like console-to-terminal-server 
> traffic is sometimes reflected back to the console as input, 
> but only when tip is being started and not every time at that.   
> 
> Some help from the comp.sys.raspberry-pi newsgroup
> suggested trying
> journalctl -u ssh
> on the RPiOS workstation. It reports ssh server activity,
> essentially sshd startups at boot, but not client activity. 
> I'll keep looking.


===
Mark Millard
marklmi at yahoo.com