From nobody Thu Jan 18 19:32:14 2024 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 4TGCYl6Shmz56nrs for ; Thu, 18 Jan 2024 19:32:11 +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 4TGCYl39Q7z4RN7 for ; Thu, 18 Jan 2024 19:32:11 +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 40IJWEg4043902 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 18 Jan 2024 11:32:15 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40IJWEN0043901; Thu, 18 Jan 2024 11:32:14 -0800 (PST) (envelope-from fbsd) Date: Thu, 18 Jan 2024 11:32:14 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: sshd signal 11 on -current Message-ID: References: <7EF12F55-70E4-4780-BF73-3C7B963C3781@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: X-Rspamd-Queue-Id: 4TGCYl39Q7z4RN7 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] On Wed, Jan 17, 2024 at 08:22:50PM -0800, Mark Millard wrote: > On Jan 17, 2024, at 17:51, bob prohaska wrote: > > > On Wed, Jan 17, 2024 at 05:09:32PM -0800, Mark Millard wrote: > >> > >> So far it sounds like the problem requires pi4 RasPiOS > >> workstation behavior to be involved to get the problem. > >> Can you do something to avoid all use of RasPiOS, possibly > >> using a different OS on that RPi4B for some experiments? > >> > > I just tried a Windows 10 laptop wired into the LAN. Ssh to > > ns2.zefox.net and running > > grep -i /var/log/messages produces five lines of grep matches, > > then "corrupted MAC on input....." > > > > I'm not sure which MAC (as in ethernet MAC) is being referred > > to. Might a different kind of MAC exist, unrelated to ethernet? > > > > Running top, or cat /var/log/messages, produces the error > > immediately. It seems safe to use ls. Meanwhile, the serial > > console session served by nemesis.zefox.com is still up > > and usable. > > > > I'm increasingly confused about where the error starts. > > > > Note: I'm using unique switch naming below, something > your diagram does not provide. > > Both the macOS system and the pi4 RasPiOS workstation > used the path (or so I assume): > > MACHINE<->wifi<->lan<->router<->switchA<->ns2.zefox.net > > What about the Windows 10 laptop test? Same path? > I've edited http://www.zefox.net/~fbsd/netmap to reflect the actual placement of hosts relative to the switches. > Could a MACHINE with the problem be moved to be > on switchA for EtherNet to see if it still has the > problem when there (just for the test)? Testing the > macOS system on switchA to be sure it still works > could also be of interest. If by MACHINE you mean the ssh client, pelorus.zefox.org is already there, along with ns1, ns2 and www.zefox.net. It's somewhat curious that going from RPi4 workstation vi ssh to www.zefox.net and then ssh to ns2 does not report corrupted MAC, but both machines run armv7 FreeBSD 12.4.4 A three hop connection (RPiOS > www.zefox.net > ns2.zefox.net) somehow inhibits the corrupted MAC error. Evidently there's something special going on among the hosts. > Could you boot a FreeBSD microsd card in the pi4 > instead and try it as a FreeBSD system to see if > it still has the problem (while in its usual > place)? I'm still looking for the same hardware > context but running a distinct but known OS > context to see if the problem persists. > Realistically I should probably just set up a microSD using 14-Release and configure it as ns2.zefox.net. That needs doing anyway and should be done for www.zefox.net and ns1.zefox.net as a matter of maintenance. The dilemma is then armv7 vs aarch64. Armv7 has served well, and used to fit in 1 GB RAM. Now it's getting tighter. Aarch64 is _very_ tight in 1 GB RAM now and will doubtless get worse. Is there a concensus on which to choose? I gather armv7's days are numbered but not up yet. Thanks for reading! bob prohaska