Re: USB-serial adapter suggestions needed

On Dec 27, 2023, at 10:55, bob prohaska <fbsd@www.zefox.net> wrote:

> Here's another example of a spontaneous disconnect, followed by
> brining the ssh session back up and re-starting tip. The USB end
> of the link is a 14-release Pi3 on the local network,

So it is not shown in http://www.zefox.net/~fbsd/netmap ?

It would be to the right-of/below "lan", possibly to the
right-of/below wifi?

> so it does
> not see ssh door-knocking. The serial console display is on a host
> which is on the public Net and so does see frequent ssh attacks


For the just below, which machine is connected to which
machine via what technique (ssh vs. tip), including any
staging of multiple stages?

> login: 
> login: Login timed out after 300 seconds
> Dec 26 17:56:56 www login[8694]: 1 LOGIN FAILURE ON ttyu1
> 
> FreeBSD/arm64 (www.zefox.org) (ttyu1)
> 
> login: 
> 
> FreeBSD/arm64 (www.zefox.org) (ttyu1)
> 
> login: 
> 
> FreeBSD/arm64 (www.zefox.org) (ttyu1)
> 
> login: client_loop: send disconnect: Broken pipe
> bob@raspberrypi:~ $ ssh 192.168.1.10

Is @raspberrypi the "pi4 RasPiOS workstation" in the
diagram?

The diagram does not show "192.168.1.10" style notation
for anything.

> Password for bob@pelorus:
> Last login: Thu Dec 28 23:01:43 2023
> FreeBSD 14.0-RELEASE-p4 (GENERIC) #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023

The diagram shows releng/14 explicitly only for:

|---50.1.20.26 www.zefox.com Pi2 releng/14 ftdi usb-serial---50.1.20.24

(There are 3 "-current" and 3 "12.3" as well.)

So, is 192.168.1.10 that "Pi2 releng/14"?

> . . .
> -- Benedict Reuschling <bcr@FreeBSD.org>
> bob@pelorus:~ % su
> Password:
> # tip ucom
> Stale lock on cuaU0 PID=1312... overriding.
> connected
> Dec 26 2pts exce [enter typed, this looks like a log entry from the public host]
> Password:        [but how did it get reflected back to that host as input?]
> Login incorrect
> login:

So is the login prompt from:

|---50.1.20.24 pelorus.zefox.org Pi3 -current

via the earlier  "ftdi usb-serial---50.1.20.24"?


> It isn't surprising to see leftover data flushing into the USB end host
> when tip opens the serial connection. It is surprising that the host at
> the serial end of the line sees some of that data as input, at least to me.

Overall I've not been able to understand what the
(various?) hypothesized stage-by-stage byte flow
paths are in these notes.

> Maybe I simply misunderstand ...... Does getty not flush input before asking
> for a login and password? Is echo happening between tip sessions?

For the RPi*'s involved, what does each config.txt have for content
and what vintage of RPi* firmware is involved? These get into if the
PL011 vs. mini-UART are in use.

As I remember it used to be that:

RPi2B v1.1 had the PL011     bound to the serial connection by default (a.k.a.: as primary)
RPi3B      had the mini-UART bound to the serial connection by default (a.k.a.: as primary)
and:
RPi2B v1.1 had the mini-UART as secondary but not bound to anything
RPi3B      had the PL011     as secondary and bound to Bluetooth

(The RPi4B is like the RPi3B in this respect, as I remember.)

The PL011 is the fully functional UART.

What is your:

dtoverlay=disable-bt
vs.
dtoverlay=miniuart-bt
vs.
Niether

status for each RPi3B/4B that is involved?


===
Mark Millard
marklmi at yahoo.com