From nobody Sun Oct 29 18:47:14 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 4SJQPg6Jv5z4y3pL for ; Sun, 29 Oct 2023 18:47:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SJQPg3m1Tz4MNQ for ; Sun, 29 Oct 2023 18:47:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698605253; bh=02JUrx4q+ZIoCy5h/g9wcmJ69TWY36KZkCbs26aAYHw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oZUBTYV5Yo+MQfV0BgIGbG/maWLT2oCtGKFcajMyjuIk7Z8eXrcgrKTNzR+qrRnIkss0RRn3ScWSqXOZeY2AOkadN8S05HjE1guxjtK3V/NPt8k/xYgUwIBySy03RaN1uj5s3Ww4hPfYlQgDStVXg8kADrMQvsNYlHCBpQTSmdwSF0YDcmomhXLE7TP0bnzNJPn7TqrQCsCflrCzIS4BtnNuDmHxe97E/VEPixJXP38tq9T0p/dEvJKQgrJZtL26eZSE+xeQNh9sy/5ykL7Ejxzm1vKs3lx/380VBFxlI0iRP3DWt6HLFuHWg6ZctuErE23sme8DfUu82GCh9zBeHg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698605253; bh=ppPsN8oCYwqeXwUK5OuZlm6AOuX6PtxplXjhRw16vvX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hoheLL9CKj6wXNq9+ipv546ORDJbS4HwVOY65uaqOi0ILCc9CIyDXR1ltjfGGSw8h5UWoPSEKMbY4/4Itgab6HCsABrPkUq9W2rhbGb3n1z80h/bC5UEJkyEWycfIY1j6UxM9rikkGrEiC5ox2+hOPnC1vJtL/Yx1AbXxxH41irQc2DCXmjpc5aBCywNDhwBxetXB/by9ncqYs7cBAn1bZlwwyVA0eMfoU9pU24m9/dCISe1rWk32qM4agyBMzQuSoB/1Eu8qDgggxGzONf+dWrc1/8dSc9TXMhZ+1AIoXJnUwvftKj26rczQuszIKVKGQLdjgW9L0fUVZwe+Tmpdg== X-YMail-OSG: s3poo8EVM1k0uLmemnoOFgk4WjyXnxcLMj.0Oe0GnxwRIZ7RIHyJMf5QsTamN2s 0PLV8ThFXW5WHjffCEtdezVzsMghgtYiyqNiAqhG_pPVnk3.TcqiZ7rjzrA84ZZopxUm9EBxDjqy tKJ3KSHOFrg.n.pthSXIntBJ22F6sLZqU3paJZtY2ZSrLnuIPELTAXYxTe2L_tTBG3fBlAte0139 DSbPnH0GJkxeeKHiqxbHdtdciJv2K1ZbU7eYCiGhWmfKmXdyEOfczgIKrsPv.7MnPv00PFUV5NNJ .1APOd0MvWXzsL7vbHbRp0xxu9tmv9vMhs4klB2EtNfYHI6UC29Bd4MmWCo0NFdnOnxrGEA6S1N0 Ka3mcemeXaMLMNh0PGNjf7d3i43qzMRJQ.mV4XBqeLM3r0e7brBtp3XgFBbFTtuDSM_IRdj6TGNf ucwbkAnAdBVdUIaq0juA6Ut7RsyKiuOolgrPJAhd1SsgXDnzFvz3ZrsbTIAou_X9Fo7ZooCCGvSe eHsTzt53pnwaROJqz9TTwErI.fV0kGc0g.B5gMV6TO800KQ7WhThatxilm_F8MHBHAD2BZ38lwmY J7QS9Z3fhDs180Fg.XD1OBamfjTDtcE6Y.DjM7CLxQRVdnWos9OTYLuB0XYTbFu1Qay4ipYYdBi8 .URgYI_ilAEHK1uHXHZaQj.6Z14fL7wfdzjT7K1MvUSmD.lAofEi6cZvVKtATiKsU4Ohy40fabah y9vTweVnLwATmck5rY_V_ywGRbwvkCCxhjt_Co9z8beyi06Lqdzipgk5AMtxkLsvZXjK8fn0khKu g5ZwIM9Mixa5vjsecFGy1cYfHjOIHCCn6j.IcUWcPDxR1qIzBOVUMshtr_AZbUfKVL_2uQ__FFxl I6MpXnQ.ZGCQ7QVvx.AcAltIyHLVCA7AoNlY90uC8fDYhj9kYB9UKzAhwa0h0w88tZ9myGs8Qxl. bqF1O3LfSdmA0jDPaNygVIlbc3Di1yFJ9sqYcVi.KXBPMaLZyyaMSiLUMseUJ36R863d1O._ioPP pc8879n0.uNN3v21oNezlsADFZynol.NT0XAvV0f26F7mQM5OpBoV7Yfg.wy0rMQE__LDawx9rdZ dumP8rHir0kGaH1KInOu_0654M.CYTpsF8bpNy9443Tw3ACl0bVnzK4IkuM3DNRTaD9ofsw7FyzO SVvVwgJZyW9R53Hw584kY6.s1ZdvhlePrNmC09pyD8uZ1Cmxi6HPbE5vIpVO09fMnigtrNZtmMHA l446jcXOiqj95QQzKkhJKumIJvZ2rAAtcTogRpkUHIy6tg3NQ3BmnqD4zKD8uTgL7FKgL2jmxs4e gUP81qxiCcZJNdczZC1KQEvcVnutI6jSjcg_4wpKoOw9_qV8523CCvIwXXGOnVK4jUdxi2WGIpgB ll6SBEvw2pE30qUIrqZFcQrlq9tyrWKLUaVzc.pkr3et8Lk_Vog5osKbFmwfZDaYuKNAnRnwmrfu PqqIaeczKVw82VMZRWgTUYJKm4OTESyfcloMUtvoDARmEXeTaTpnP8EdFpeUhLZoHjnC5IudPjQY lSe5jGjDBZUnVT0_6jEC6LRXbZqbw9ikkvK4wE1PdG0MKfbC.6EuE_iAOnZP1FkzuiG4x0dmUg.2 Ug_yRlZ081n8hoQ6ckBN0D_HbmCwqMR2ry7iBujYYBY0N2SwqzzTBZhG5FKPjJJ2W5.d7SCWzGU4 edK0rOdWuHtk3MmEUSAjvZCKmVY812Viw1xnbU2fhdbIgETk3duQxfSENuhnKVfxgZJPDOqrUnI8 DYjnDHMjujwvICdPvUWFjCcZB.XjE3J4Mhz2op.eHwaurzXGOYPe3wNnatUnohIdt1G7rgr3wpqk Dmih6cMsBzMBzcbpeGcgQA_JgBoEhfPLIcRKaCcNgKdIN9vanxZKczZ7dkbFcBtFXjSdanZoKXem MmjLjWVABA0zMtfocEA2B5i1UCRAayvJqgOyw0T9oy756Qea2bOHzkxI4QHWxLevG9RuNKwm27Mg W33iu2HZgqux2Hy8Ue7qKyS.DIfQZCVBDRS3q3trc5ViC5m8FFsfrpz_U8UmrFer6g6BPUdCGI4Q 31KbDrs0yQN.bQPQDy7eIleG8hn5FnXOWeaGDlnY5c9qRibKCm3JK0QWWlVCgV4gdbdcisTwLLEr Scpcj8nfl1JdlL14R9odzvntTifKaIjjSgHlch7ocY1HIDGl88X0Figasfrh1.8pcV46D0sVfwUR 2T3RtcacYmZHdW0zlUCVyYYyv_rEZFNbFbjKj.eJqtBu8g09X916kXAoC2Y0H1ceawB5nG.m9UDv 50g-- X-Sonic-MF: X-Sonic-ID: 1b399d20-e76a-4304-a484-b093e4335a58 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Oct 2023 18:47:33 +0000 Received: by hermes--production-bf1-5b945b6d47-ssgx9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1845bad53d5189e12cef3150d169d38f; Sun, 29 Oct 2023 18:47:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter From: Mark Millard In-Reply-To: Date: Sun, 29 Oct 2023 11:47:14 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <90CBBDDB-654B-402B-96E8-C16545BFE011@yahoo.com> References: <33D1AACD-62FB-444A-868C-B8DE92A7BF50@yahoo.com> <5210D449-A4E6-455B-A1BB-754BA3501C3F@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.200.91.1.1) 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:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4SJQPg3m1Tz4MNQ On Oct 29, 2023, at 07:01, bob prohaska wrote: > 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: >>=20 >> 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) >>=20 >=20 > I think you've got the picture. Here's an ASCII-art diagram: > http://www.zefox.net/~fbsd/netmap >=20 > 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. >=20 >=20 >> (An accurate/complete indication of the sessions/connections >> command sequence for the set up could be useful.) >>=20 >=20 > 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 >=20 . . . > bob@www:~ % su > Password: > # usbconfig > ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DSAVE (0mA) > ugen1.2: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (2mA) > ugen1.3: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DON (2mA) > ugen1.4: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DON (90mA) > ugen1.5: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (100mA) > ugen1.6: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DON (500mA) > # tip ucom > Stale lock on cuaU0 PID=3D1272... overriding. > connected >=20 >=20 > FreeBSD/arm64 (pelorus.zefox.org) (ttyu0) >=20 >=20 >> As I understand, you are seeing the ssh session abort, not just a tip >> session abort. >>=20 >=20 > That's correct. On the RasPiOS host I see simply > client_loop: send disconnect: Broken pipe >=20 >> 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: >>=20 >> 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? >>=20 >> So, a comparison/contrast test. >>=20 >=20 > 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. I take that wording to mean that the ssh session into: 50.1.20.26 www.zefox.com Pi2 releng/14 fails, 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?). 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. It would be possible to do similarly on more than one target RPi*, not just the releng/14 RPi2B v1.1 . The test would be for whichever target RPi* happens to show the failure. >> 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. >>=20 >> I've no clue if "tip -n -v" might report anything interesting around >> a failure (via the -v). >=20 > I've tried ssh -e none, it didn't make an obvious difference. I = overlooked=20 > 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=20 > 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.=20 > I'll try tip -n -v at the next opportunity. =3D=3D=3D Mark Millard marklmi at yahoo.com