Re: USB-serial adapter suggestions needed

On Jan 11, 2024, at 13:28, Mark Millard <[email protected]> wrote:

> On Jan 11, 2024, at 12:12, bob prohaska <[email protected]> wrote:
> 
>> On Wed, Jan 10, 2024 at 09:34:00PM -0800, Mark Millard wrote:
>>> 
>>> "&" creates background processes that are still killed when
>>> their parent tty or controlling process goes away. nohup
>>> avoids that kill.
>> 
>> Not sure what's going on, but if I use 
>> make buildworld &
>> on one of my RPi* hosts and log out or otherwise drop
>> the connection, the job keeps going. Maybe use of tcsh?
>> 
>>> 
>>> What was running on nemesis.zefox.com was its side of the
>>> ssh that in turn was attached to the shell that in turn
>>> was running tip --until those exited/were-killed on
>>> nemesis.zefox.com .
>>> 
>>> 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?
>>> 
>> 
>> 
>> I've put relevant excerpts from /var/log/messages from
>> ns2.zefox.net (the console host) and nemesis.zefox.com
>> (the terminal server) at
>> http://www.zefox.net/~fbsd/tiptrouble/
>> They've been trimmed to the tip failure timeframe.
> 
> Note the "ucom_close" and "ucom_shutdown" and "ucom_cfg_close"
> in:
> 
> Jan 10 14:12:54 nemesis syslogd: last message repeated 1 times
> Jan 10 14:16:35 nemesis kernel: ucom_outwakeup: sc = 0xffffa00002466088
> Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=1
> Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=0
> Jan 10 14:16:35 nemesis kernel: ucom_inwakeup: tp=0xffffa00001979800
> Jan 10 14:16:35 nemesis syslogd: last message repeated 1 times
> Jan 10 14:26:40 nemesis syslogd: last message repeated 1 times
> Jan 10 14:29:48 nemesis syslogd: last message repeated 3 times
> Jan 10 14:29:48 nemesis kernel: ucom_close: tp=0xffffa00001979800
> Jan 10 14:29:48 nemesis kernel: ucom_shutdown: 
> Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff = 0
> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x00, off=0x01
> Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff = 1
> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x02, off=0x00
> Jan 10 14:29:48 nemesis kernel: ucom_cfg_close: 
> Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4
> 
> Note the time frame vs. your reported:
> 
> QUOTE
> Jan 10 13:14:06 ns2 sshd[48381]: fatal: Timeout before authentication for 59.56.110.106 port 50300
> Jan 10 13:34:34 ns2 sshd[926]: error: beginning MaxStartups throttling
> Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for illegal user shutdown from 185.11.61.234
> 
> 
> FreeBSD/arm (ns2.zefox.net) (ttyu0)
> 
> login: client_loop: send disconnect: Broken pipe
> bob@raspberrypi:~ $ 
> END QUOTE
> 
> Looks to me like something lead to ucom stopping on
> nemesis.zefox.com .
> 
> The ns2.zefox.net shows:
> 
> QUOTE
> Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for illegal user shutdown from 185.11.61.234
> Jan 10 14:26:28 ns2 sshd[48524]: error: Fssh_kex_exchange_identification: Connection closed by remote host
> Jan 10 14:43:28 ns2 sshd[48546]: error: PAM: Authentication error for illegal user test from 85.209.11.226
> Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 20 seq 2 [preauth]
> Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 30 seq 3 [preauth]
> END QUOTE
> 
> It does not suggest ns2.zefox.net as starting the sequence.
> 
> 
>> There is a link to a copy of nemesis's sshd_debug.log file at
>> http://nemesis.zefox.com/~bob/fbsd/sshd_debug.log
>> The file seems too big to search interactively via a
>> browser, but it might be possible to download it in
>> one pass and then grep locally. For some reason it
>> isn't timestamped in any way I recognize. 
>> 
>>> We only know that the end result was lack of anything
>>> reading the pipe on nemesis.zefox.com : by then
>>> the ssh side on nemesis.zefox.com had stopped being
>>> set up to read the pipe.
>>> 
>>> 
>>> Did you look at /var/logs/messages [or the analogous linux
>>> place(s)] on "pi4 RasPiOS workstation"?  What, if anything, did
>>> such have from around the failure time frame?
>>> 
>>> 
>> I tried, but the naming is very different from FreeBSD and I
>> didn't recognize any obvious candidates. I'll look more later.
> 
> Looking around I found in:
> 
> https://askubuntu.com/questions/26237/difference-between-var-log-messages-var-log-syslog-and-var-log-kern-log
> 
> QUOTE
> 2020 update
> 
> You may still stumble upon syslog; but the defaults have changed.
> journald has replaced syslog, in quite a big portion of systems, including Ubuntu.
> 
> This is relevant because you won't be finding /var/log/messages that often anymore. journald doesn't write plaintext logs — it uses its own, compressed and partially authenticated format.
> 
> Search online for e.g. journalctl cheatsheet, or just study man 8 systemd-journald, man 1 journalctl yourself.
> 
> Syslog and journald are, to a degree, cross-compatible; you can transport logs between them in either direction. However, you won't get plaintext logs a-la /var/log/messages with journald; and you won't get structured (journalctl -o json-pretty) and authenticated logging with syslog.
> END QUOTE
> 
>> Meanwhile, the non-ssh-mediated tip session from 
>> nemesis.zefox.com to ns2.zefox.net's console gpio pins
>> remains up.
>> 
> 
> Looks like the 110 MiByte or so file will take an hour
> or so to transfer from when I started it.
> 

The big file does have exactly one example of:

Fssh_send_error: write: Broken pipe

(This ignores "Connection from " lines that report "Broken pipe".)


===
Mark Millard
marklmi at yahoo.com