From nobody Mon Oct 30 14:31:50 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 4SJwhB5S9Cz4y0mx for ; Mon, 30 Oct 2023 14:31:54 +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 4SJwhB2J8kz3Hlq for ; Mon, 30 Oct 2023 14:31:54 +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 39UEVo61090150 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 30 Oct 2023 07:31:50 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 39UEVoOp090149; Mon, 30 Oct 2023 07:31:50 -0700 (PDT) (envelope-from fbsd) Date: Mon, 30 Oct 2023 07:31:50 -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> <90CBBDDB-654B-402B-96E8-C16545BFE011@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: <90CBBDDB-654B-402B-96E8-C16545BFE011@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: 4SJwhB2J8kz3Hlq On Sun, Oct 29, 2023 at 11:47:14AM -0700, Mark Millard wrote: > > I take that wording to mean that the ssh session into: > > 50.1.20.26 www.zefox.com Pi2 releng/14 > > fails, Correct. > not the ssh session into: > > 50.1.20.27 www.zefox.net Pi2 12.3 2303 usb-serial----50.1.20.26 > > If I have that wrong, my wording below would need adjustment. > > So my suggestion would be to have an extra ssh session to the releng/14 > RPi2B v1.1 in order to see if both ssh's have problems at the same time. > I'm not suggesting a 2nd serial connection: the extra ssh session would > just sit at a releng/14 shell prompt, for example. > > On failure, a question would be if the extra ssh session can still > execute commands in that shell or not. > > If only one ssh session of the pair fails, repeated testing to check if > it is always the same one of the pair would be appropriate (always and > only the one doing tip?). > As a rule, in addition to the ssh session running tip there's also an ssh session running other tasks, often in the background, like buildworld. Those didn't normally drop. > This might help issolate if tip is involved in initiating the ssh falure > or not. tip would likely stop if the ssh session failed for other reasons. > > I recommend the experiments be with "ssh -e none" and "tip -n -v", even if > the likes of, say, "tip -n" is unreasonable in general use. > > > 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. > > I'm not really after what happens across multiple RPi*'s in my > suggestion. I'm after the pair of ssh sessions into the same > RPi* instead --just for the target RPi* that gets the failure. At the moment the relevant ssh session uses -e none and tip uses -n -v, and the session stayed up all night. However, there's another change: When preparing to post the link to the network/serial map it dawned on me that the host in question was still on the wired LAN (for configuration), not the public WAN. To my thinking that really shouldn't matter but maybe it does, and the wired WAN is the ultimate destination for the host anyway, so I moved it. The wired LAN doesn't see much use, so its performance isn't well characterized. Apologies for the last-minute revelation 8-( Thanks for writing, bob prohaska