Re: USB-serial adapter suggestions needed

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
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.


===
Mark Millard
marklmi at yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.