Re: USB-serial adapter suggestions needed

On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Millard wrote:
> 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.
It's the host named pelorus, formerly 50.1.20.24
The network cabled was simply moved from WAN to LAN.


> 
> > 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"?
> 
> > . . 
No, the Pi2 isn't involved. 

> > -- 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"?
>

No, the garbled login prompt originates from www.zefox.org's
serial console. It's via an ssh session running on 
pelorus but displayed on the RasPiOS workstation. 



> 
> > 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.
>
 
Understood, it's been hard to articulate 8-( Maybe
Workstation > ethernet > pelorus > usb port > gpio 8,10 > console www.zefox.org
is a little clearer 
> 
> 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.
> 

I'm using the default serial console port on pins 8, 10 and 12 on all
of the Pi's involved. 

The Pi3 which reported the garbled login prompt 
uses in config.txt:
b@www:/boot/msdos % more config.txt
init_uart_clock=3000000
enable_uart=1
kernel=u-boot.bin
kernel7=u-boot.bin
dtoverlay=mmc
force_mac_address=b8:27:eb:71:46:4f

The Pi3 hosting the usb-serial adapter has in config.txt
bob@pelorus:~ % more /boot/efi/config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin

[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin



> 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?

For the Pi3 using its uart in this chain, neither 

For the Pi3 using ethernet and usb, dtoverlay=disable-bt 

Thanks for reading!

bob prohaska