From nobody Fri Jan 19 19:40:55 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 4TGqjf4z89z57FHY for ; Fri, 19 Jan 2024 19:41:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.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 4TGqjf1G47z4swm for ; Fri, 19 Jan 2024 19:41:10 +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=1705693267; bh=4bgIpwfAiXH6QZl84J9clkQTUE91DxeMMxJJEUhwKs8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qWQUTocONSrdKlxWOsgzl/NISYkwWpjaAY2WLDp0CMj6Y4Op5e4lzxzcH7Y1+uMIZbGDsB9v7GOebp/86MKhxgq7U0A8FCxH/+OZ4v+3W8ROZKFdoXnACPRLu1Zo4hTvc5MmagDh+v92L9NcLJ6YS8hCuDm5JAWRLK1PoMMwDXTuv/PDMihL2UB8HIoGXZJZQhsWuHtJ/uMk71KmE3NhRNIeJaNRIAE/5QnVE9uxFIMV2pX4pA2bKB28D52sBjBTC9Y1AE8ihl+dNYYiMrDOFhOHCH0XBJ8OfUFEJMDUK7YMSBQGlddl/x0jT9M/WGn7N03u0kdZYN123YXWGo6SSw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705693267; bh=jCKd//ad6/0Jx0QQ7I6IcFLvAB+N5tbynVBayA20hQZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=STY1ws+mougQOGNcaiP6MYNBIGx89UbOJlF9AXbNjUSmZTZL8yoVbUSdGiA6la+v4WDhSs5leCfvyidBmT7kVEKo/HTP8gUAj2g0rfLJ24CWmk9fQajXE6T+bHlG8iS0qXoAqWUc1SZuCoY3ZbqLfOCj/qgBYzAc18RQUAUyFOMipgIAanHt8mcDU6WlnLjC42U2i2L5bZh8aV0x6B/uxm7HwtvaBBKVfOdEHTDlpTGhmLXZ+z/oPOew8Tg2nXXNv0Nrryzl1GTqtb5KIE3MmP3NTooeOFzwrssyJez+el++ws7q164rpQpy/iv7An3CQMl53Cmh+DXRyFZYQFOuPQ== X-YMail-OSG: Z5Wwe4sVM1lLi84nX7UFhUjgkKoaaSV09wJTxRwshmpPeG8TvIUckehgo1dUNCJ yD8RZ0DgniNY8TQKhLP5KxBHezMXBejfBytG1G5lq8L2ICGrZlFv4jCAhgdXEteFPs1oMnXDluY. RqV4YnBt1.9_07PXHUXqH3DjiiPZJRE7FXZrEY4KOZfUj2YdZlI01cjMtX7kiELK0lObx7DawACu kq9rjMBvAmdf.lJBtJRM6P0Tw_KIImwZL4.oeWwH5h5c7M6A9RRzTK3VxlTj_DLbAAmG5bvUqVgZ RT.TOxtNVf9uhPtysE749TPbdco9DZ.t9HuFHLUqqZDDN0WO0yp0whv4hqyuIAdeleHMxHBy.9xs bfaxHPrkbypq8MXxw0fWU7MF20fUkOVzUVfbVAlAUlx7_kT8BQQPobIGRaR_iOTiRHYEfX9ocHtM JWoz5_QJNvYhQKtTlcsMo57_iJKiQIwwi8eLcA7vlvEXf6DPCzrXguMNwSCs0YqtMBHuaZIHZCSC WtqNshU28NmIjZVrxSeKH5QD7WuwfKkWoiseDcqQecXg.i9QiycJUHi3qAe2R6Y5ul4fyiguaS05 F4isM_OLplJtaTThdM3WXa6vHW3jbzROOuYqjorJ9UnvM9KTFxaW1Ie.jr12g70UQWqUVJqChEP8 7IyAs1DOpzhi5Fy8M2l.CLoCaddSEH0FZSd88zD1iX0DkhcVpC7Rm46Xn.HB6MVAqHL0_PyeOnXX ZbqLuWdZAqy3t1y3wIpV3EHtp9Cy..4oRJHscyd3jS8OfZKRCNuMZaz2GpK.5naYdt7C1YmqhsWf zwAaVwO7XhV1zGdCGkZeiuha35JkSgPkGUM5igoULO3CyI.nYUg5vgHrEaLx1oXPbjnzxfNMgpWd XjZoWW8AHATXis8uwkv9f6oIQPY8UgRvt0gDUrM2htAxDfcDikRkaPmOk_wlYI2V4mvphBvB6CPT egOvoliNWnfIHy1S.OGZYzJZ4sDFybmstw0Or8AU.bbFHWA3njM9_XLt3EmVWdWL9vnXwi4iU7QJ rq4pW.8UOwUcQgshEFW4K1VWx1HjBmKC5jiJgzJtRN2gp50nnOVLjp1PQ79bU0VzSj9VMZJ0YTF. kOBpthiHEy45aBqNrAhO3haQgZ9NnkB3AC3HYieNlQnlKSLX5yq.PcpWglrnvRBd0CpX5AC8lJUE 3mU5g3eLfFqNn7mUVBzfvqW7Jt4e9m42kc60sbvzA1FH2YKgtzqg80QFGTSF3q_9L4.rxuyOXhMZ oBu.8v7qicVVheGJls2DK5nMujYQqV17q41JFrOHfR9eDWNu0xPCN3Kv2WFbl8y30o8gq713.vGu PNkPEVu.ALp6EOSR9hXl.Kh6Y5Mr9OpNWF1sKy1zb3_Co6JvGcUWvkrmgbvtHd4ekFy0MJ1w9C6x 5yKJIXfhqc7O7zznKj8U_59mgOwyLaKT6_eIolThkRcMnPzo2fmZ1SlPhltZXVzwadX.A9yfN7Ti SUfwKonfjdjt9HEXlNVQ029v26rjjsIS15D3rT1LGGBYwVtVybeTI66Ziciug_8yXQ2ujNUJD.9O o3lCCCzycNbY4zRKFh96RV7DjRleEkkGPNQ9uv9yOxiw.XXuiq_QrmVP4P3Q_VHDKtVJBZ5KnOCt ZphdQiY4501KGYIst2iiHpGUCmHsaIWMC8zFLsrNS_fuEcqRgKG_mKyZTg8hPjFvOE0O29yrikgd muaziLeNwJiAKQ0Wyj4MG6mSVRy90OlfYdmAx2kN2nqgk_52OMbIKMQ_rpRB0zfvmk2RimIE8aWD tcJu7VpT1S3mtKCBDY3CEPsZNsEKl8Cp6p9K58wcxavdnSCCWMEnl3j2mNIBgEXXfqy1uLVjpbSv Szejvie4NfBOSavojQamZlhHdBPmBHMOD5d5q.zdPfFGxZqrbwId6rvydPbf3DjJuG5NtvYKSy0m RTHHXvhGvC84E2BVfKuc.9_OFTnf5YY4P0nh1UyotAv047iXM_zgDCWIu5P0h6z4A9yFmbib45H2 MEWPuxS_S_ej8Wkm.Jw4lIM9khP5OrBkQrAjSZ.lzRt92qFSdRquFNnJZ0N.tioGlF03yjHounVK APJSqdHD7ZN5be.Q39ITZriYVLlgdkLTm_n3iDZkqgjOLQdUwytJ5qxa1FPEh2Se7dcqt29oY2N_ iM44PWZ.HMLIypuVzWZVjS9sl.Dg9WRkEDo_0.Ldgw94K_qw5xVjaWj2rV5AEK_ZONfodFzlS1YQ d3ENICg0XYsIqEQxw0BJjj1CtlOiMZoW.xtD4z0lt1jigUlQ0WLNSYl1FmnWZgfszT.rGNS1WkJ6 8gA-- X-Sonic-MF: X-Sonic-ID: f4facf5c-4fd7-4879-a82e-0a44f76b62a2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Jan 2024 19:41:07 +0000 Received: by hermes--production-gq1-78d49cd6df-xzd4p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dcb7f5fd75a48c173c1f909243fc91f4; Fri, 19 Jan 2024 19:41:06 +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.300.61.1.2\)) Subject: Re: sshd signal 11 on -current From: Mark Millard In-Reply-To: Date: Fri, 19 Jan 2024 11:40:55 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7EF12F55-70E4-4780-BF73-3C7B963C3781@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TGqjf1G47z4swm 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] On Jan 19, 2024, at 10:57, bob prohaska wrote: > On Thu, Jan 18, 2024 at 02:11:03PM -0800, Mark Millard wrote: >>=20 >> This means I'm now focused on just: >>=20 >> MACHINE<->lan<->router<->switchA<->ns2.zefox.net >>=20 >> and possibly eliminating more stages as not required >> to get the problem. >>=20 >> Now can lan and/or router be eliminated by moving >> one of "Win10 laptp" or "pi4 RaspIS workstation" >> temporarily? Moving to switchA would be testing not >> having either lan or router involved: >=20 > Not easily. I'd hesitate to configure either host > for exposure to the public WAN. I could move ns2, > but would want to configure a replacement first. You may need to do local experiments where the dsl_modem is not connected? Or may be move switchA to the other side of the router temporarily? Problem isolation may require things be off the public WAN some of the time. >> MACHINE<->switchA<->ns2.zefox.net >>=20 >> Does such a move lead to still having the MAC >> failure? To no MAC failure? >>=20 >=20 > ns2.zefox.net is on switchA with four other FreeBSD > machines. Two of them, www.zefox.org (aarch64-current)=20 > and www.zefox.net (armv7 12.4.4) accept and hold ssh > connections without error from any host on WAN or LAN. > They also run the "grep -i ssh /var/log/messages" command > but it dosen't elicit the "corrupt MAC..." message=20 > and disconnect. Which tells me nothing about if RasPiOS or Win10 would also work. Those are all FreeBSD-only combinations. Remember that macOS being involved also did not get the failure despite its context also being: MACHINE<->wifi<->lan<->router<->switchA<->ns2.zefox.net The only difference vs. RasPiOS was it being a macOS system and hardware. >> (Switches, routers, and the like do sometimes have >> errors that mess up just some protocol, not >> everything.) >>=20 >=20 > But wouldn't that affect all hosts? That is what I'm trying to test, not assume. The OS's need not do all the protocol the same. So the switches need not be processing the exact same packets. > in this case=20 > ns2.zefox.net and ns1.zefox.net seem to be affected.=20 > No other hosts (so far) have reported that particular > error. If you are unable to isolate the smallest configurations that fail and which Operating System combinations fail I do not see how to get evidence for the range of observed oddities. >>> 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 >>=20 >> So, listing the nested(!) ssh sequence more fully, that was(?): >>=20 >> "pi4 RasPiOS = workstation"<->wifi<->lan<->router<->switchA<->www.zefox.net<->switchA<->n= s2.zefox.net >>=20 >> Or, being more explicit about the nesting: >>=20 >> "pi4 RasPiOS = workstation"<->wifi<->lan<->router<->switchA<->www.zefox.net >>=20 >> then, nested: >>=20 >> www.zefox.net<->switchA<->ns2.zefox.net >>=20 >> And it ends up getting the same result (no failure) >> as just doing: >>=20 >> www.zefox.net<->switchA<->ns2.zefox.net >>=20 >> without the involvement of any other MACHINE, if I >> understand right. >>=20 >=20 > Subject to the proviso that www.zefox.net is headless > and so must be accessed via ssh from some other host. No tip session attached to www.zefox.net ? That connection type is not via ssh to www.zefox.net . > The choice of host seems to make no difference. macOS vs. RasPiOS/Win10 ? >> Another related test would be by temporarily moving >> www.zefox.net to form one of: >>=20 >> www.zefox.net<->wifi<->lan<->router<->switchA<->www.zefox.net >> or: >> www.zefox.net<->lan<->router<->switchA<->www.zefox.net >>=20 >> Does such still not get a failure? Or does it then fail? >>=20 >>=20 >>> 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. >>>=20 >>>> 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. >>>>=20 >>>=20 >>> Realistically I should probably just set up a microSD using >>> 14-Release and configure it as ns2.zefox.net. >>=20 >> That is going a different direction than I asked about. >> It does not eliminate RasPiOS from involvement on the >> same hardware it was originally used on. >>=20 >> Both types of tests have their uses. But my focus for >> now in this area is on the replacement of RasPiOS by >> a FreeBSD version to eliminate RasPiOS's involvement >> for some tests but using the same hardware as before >> the replacement (other than boot media). >>=20 >=20 > I'm missing the point. RasPiOS behaves much like > Win10, But not like macOS. As I understand, with macOS involved, no errors have been able to be produced. > FreeBSD-current and an armv7 instance of > 14.0-RELEASE-p4 FreeBSD elsewhere in my network. The > mischief seems tightly confined to the legacy 12.4.4 > armv7 hosts ns1 and ns2. =20 Not true of using macOS involvement avoids the problem completely. >> armv7 is Tier 2 for 13.x and 14.x >>=20 >> armv7 is projected to stay tier 2 for the later official 15.x >> ( stable/15 and such ) but might not. It is possible that >> armv7 might only be supported via lib32/chroot/jail use for >> aarch64 that also supports EL0 AArch32 --and so AArch32/armv7 >> could end up not being bootable any more by then. >>=20 >> aarch64 is Tier 1 for 13.x and 14.x >> aarch64 is projected to stay tier 1 for the later official 15.x >> aarch64 hardware that does not support AArch32 at all would >> still be Tier 1. >> (The aarch64 tier 1 claims are somewhat strong for embedded >> aarch64. A possibility being that, at some point, a 1 GiByte >> RAM aarch64 might not be able to self-host buildworld >> buildkernel or various port->package builds even with >> substantial swap space --but that would not be likely to >> change the Tier 1 status of aarch64, for example.) >=20 > That summary makes me think abandoning armv7 in favor of > aarch64 is best. Even if it can't self-host, packages and > updates will be available. You could have a builder RPi4B (or other) system with more RAM, even 8 GiBytes. > I do apologize for the fuss of this thread. When first=20 > reported I thought there might be something potentially=20 > malicious going on. Hobby hosts make good targets for=20 > experimental attacks and some of the sshd errors looked > suspicious to a naive eye.=20 >=20 > Thanks to all (especially Mark!) who followed this saga. =3D=3D=3D Mark Millard marklmi at yahoo.com