From nobody Thu Dec 28 01:24:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0rR81N3Kz54q95 for ; Thu, 28 Dec 2023 01:25:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0rR74m86z3P8b for ; Thu, 28 Dec 2023 01:25:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BS1OwI2036884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Dec 2023 17:24:58 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BS1OusS036883; Wed, 27 Dec 2023 17:24:56 -0800 (PST) (envelope-from fbsd) Date: Wed, 27 Dec 2023 17:24:56 -0800 From: bob prohaska To: Mark Millard Cc: John F Carr , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0rR74m86z3P8b On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Millard wrote: > On Dec 27, 2023, at 10:55, bob prohaska 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 > > 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