From nobody Sun Oct 29 14:01:21 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 4SJJ3Q0kLrz4xkv4 for ; Sun, 29 Oct 2023 14:01:22 +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 4SJJ3P44tHz3WpC for ; Sun, 29 Oct 2023 14:01:21 +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 39TE1Mc0086412 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 29 Oct 2023 07:01:22 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 39TE1MY2086411; Sun, 29 Oct 2023 07:01:22 -0700 (PDT) (envelope-from fbsd) Date: Sun, 29 Oct 2023 07:01:21 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter Message-ID: References: <33D1AACD-62FB-444A-868C-B8DE92A7BF50@yahoo.com> <5210D449-A4E6-455B-A1BB-754BA3501C3F@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: <5210D449-A4E6-455B-A1BB-754BA3501C3F@yahoo.com> X-Spamd-Bar: ---- 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-Rspamd-Queue-Id: 4SJJ3P44tHz3WpC On Sat, Oct 28, 2023 at 04:11:53PM -0700, Mark Millard wrote: > So, if I understand correctly, the general structure here is something like: > > RPi4B: ssh to RPi2 v1.1 #0 (to invent simple naming). > . . . > RPi2 v1.1 #0: tip ucom (which gets to RPi2 v1.1 #1) > . . . > (Does each RPi2 v1.1 get its own ssh session too? If yes: all from the same RPi4B?) > RPi2 v1.1 #1: tip ucom (which gets to RPi2 v1.1 #2) > . . . > (ssh session to RPi2 v1.1 #N ?) > RPi2 v1.1 #N: tip ucom (which gets to RPi2 v1.1 #0) > I think you've got the picture. Here's an ASCII-art diagram: http://www.zefox.net/~fbsd/netmap Each connection originates on a single WiFi-connected Pi4 running RasPiOS (top right). The sessions are separate shells, each running in a tab in one lxterminal window. > (An accurate/complete indication of the sessions/connections > command sequence for the set up could be useful.) > Here's a verbatim sample, including MOTD and usbconfig output: bob@raspberrypi:~ $ ssh 50.1.20.26 Password for bob@www.zefox.com: Last login: Sun Oct 29 03:34:28 2023 from 50.1.20.31 FreeBSD 14.0-RC3 (GENERIC) #39 releng/14.0-n265368-c6cfdc130554-dirty: Fri Oct 27 21:27:20 PDT 2023 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://www.FreeBSD.org/lists/questions/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier To change this login announcement, see motd(5). To display the compression ratio for the ZFS dataset /var/log on the pool mypool, run the following command: zfs get refcompressratio mypool/var/log The refcompressratio will only display the compression ratio for that specific dataset, not the descendant datasets. To include the child datasets, the command looks like this: zfs get compressratio mypool/var -- Benedict Reuschling bob@www:~ % su Password: # usbconfig ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) ugen1.4: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) ugen1.5: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) ugen1.6: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) # tip ucom Stale lock on cuaU0 PID=1272... overriding. connected FreeBSD/arm64 (pelorus.zefox.org) (ttyu0) > As I understand, you are seeing the ssh session abort, not just a tip > session abort. > That's correct. On the RasPiOS host I see simply client_loop: send disconnect: Broken pipe > An interesting test might be having another ssh session paired with > each one that does a remote tip --but that is not used for any tip > or other activity beyond sitting at a shell prompt. The question for > each paired ssh session would be: > > A) Do both ssh sessions of the pair fail/abort at the same time? > B) Does only one? If yes: is it always just the one that had used tip? > > So, a comparison/contrast test. > At present I have only one usb-serial adapter per RPi2/3/4. However, that still gives me seven tip sessions up at any one time and the one on releng/14 drops reliably. There are usually half a dozen ssh connections running interactive shells from the RasPiOS host to random FreeBSD Pi's and as a rule they only drop when I crash or reboot the RasPiOS host. > As I remember, there were notes about avoiding special character > sequences from getting special interpretations for ssh. That sort of > thing could be important to both ssh [-e none] and tip [-n] for > testing if that avoids some problems. > > I've no clue if "tip -n -v" might report anything interesting around > a failure (via the -v). I've tried ssh -e none, it didn't make an obvious difference. I overlooked tip -v, will try it next time. As it happens the tip sessions sometimes come up "stuck", reporting a connection but refusing to display any output. In that case it's useful to use ~~. to escape back to a root prompt, run usbconfig [-u 0 -a 4] power_off and then power_on to reset the usb-serial adapter, which generally gets a working connection. I'll try tip -n -v at the next opportunity. Thanks for writing! bob prohaska