From nobody Tue Feb 15 05:21:02 2022 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 619D519BD21C for ; Tue, 15 Feb 2022 05:21:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyTvt3Xlbz4lND for ; Tue, 15 Feb 2022 05:21:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644902467; bh=pPWE4TrizQQzFlK4mXHMqkyXf1d55eBVtfeXEmU7BFI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dKeCndzt6UAqOKUUBe6nEJG225FLb8wXzihAeiEFTgtBulEm5n2n2HkLj2eZMlQauE6U/aI2l3kJaSuwffrPWOe4lVXWpmy5MPIYHeaNqOGcefubz8X3r15ETeRr25ZTWoAwjLUiFgSvAWdeAyvYgnHZPhMF0TFbOMu2OOV0coGB0A+UXk4LFUpd53W13sh96w7vZixvlU/sLr5aU18vDmuM1bjwiCRodMyGrzh1G5Bc3aEsRjkb2Bo1o4CkiIYid0KSuT2p4+FN2OFVvQdcB5ZFOhP2GC1HbsIGrixjqRVgAeYGnFsCYrAcKNF1SreMiwL+RxOyNhmNY10NRM8jYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644902467; bh=bh6g8LqtFC5hLt8fcaBb+R9/Z2lTRYkjGYaGdj/MFE0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=T4H7aK880FEuqRfRsUBgZpHFUNhqOzcbeZXukV8MYE4xOCHJSN4WZQCp756QbciTbY6Z95GUYO6CDcDa4ZpiGu2hxDYz5wVRObvlesPTymiWr0CRzPwNfwiQDt3iIGxNt9rbbbAYYOx7rJPo2smb1FYGk045Vzj8VZiVCVbtqU8B7IsVCVbtQFvvClJyFdJOh/ApJ2D1NLiMbOQcRbIZX7mFa0+y8SF7Li04vmdzyunMngAcdsdSFGXB3Tbsx0Gj2hbl2ZKob3kMZL4CLW8Ku4RaetgJLjpDGAQjhcofvKMjWGVhPAtfgomal3AXvG9BFpnHbixPWqwttfB7IStE8w== X-YMail-OSG: 8sHd7WEVM1mpcZ.tn5LCzrR1Tx5AoJFFOfkQzgk_3jtaRzsas.KM5BeEwkNmnI7 IKbW_z96FKoK_RsDTI7TeexSTZREDoVpEZ2uVXekN7rFib0ET6a2W0JWoBRiO9bp_DgsdSu2SkUv oWJqMd79C0sdnQnTheGt_jSdhYky1huh8dYludK9Q.ugqKY8Pgv518ZH7UxEDuuJ_y3G5D1zqvrk tYqzivzpcttpTgoajnPopTx4jMHruJnGtvm1KjhH4IHtRC8.3DXKQgbmikHbTLwEDZJ0OGbfq3Fp qK9iBhbNU15y2FMv_ENnewXNXYyv7CIUP8LM9l08I7SkH9XIrv4baT.GmFP4LAwCNfQ1_pI.686o 3lBFJT3DstjhinFRl8ouOubc_RkQIN6.uP3pAvkBDERZYRaeQDZnqhFE8hZTMk6b_WpPAf.sRQVD yb6S6aylGPU6CfD5uKBcssIxvxLorWmlFE4vQobt0abE.Q6Jr525guYpCimag4b2GerY4ntDTYTZ j4LbsM5OUuQgpAGCph6MGvc9OhWnBXLXzYjk61im7z.90tsiulSSKYlY_MVGUzTwd0TSUU_cJ5N9 cIjpLWrkeuBsDf6UeqHBGd89og0lSARal8TdjrbeWVWPLTFUf8Z4v2z.vayJJQksubLXVopg1kbA 03dBw8kvbInob0Q0XiSnopl7lBjgs43SUvFa44mcJLXSIp9ApaD66swwfZ3q5Okq_WkuiEc0E1Z5 F9LniBRDkOlFO1XwHNsyGVX6Sq5.tuMsvjDkpDA_IHKmHu9IdnZDhTFGw93KhteSZswde_8dC5JQ 1nznA465Auj_y9smBrsEXqTnwiiyqDVYKdHWzj6L3lJtYmCOXiGbaZ8xEIlN3C5vbgkkIalIHdN4 DNGaA8KOWU5oNRQa1mWSlDvJacHrRbfOuEwS4M6BY40FjsXy6hTUCYR5WqA4uPXpTcAboR5WFWvY KokjNext4MIeF1w.BQwOaQNYu_QcFFeXsYzuks2X5SiODidrF_qyrJDVTvHy43FRoc6Mlcm3RRXR Kfvsh2_jF0vrKURFl47TAl7trBDav04q0yE2DU39E3WfC.srGRmjaDmAdTEZcNL7rIYrZBZ9JReE zS4z9T9p6qxW28aosbuHbcj4jlpCrcEEm8SeMRm.uU7asIcYcKBiRQ4Ycx8K3vtFs1a4F5TIhYN9 d8CkJDWeoF8kCTwo3.UvaqZgbjnUXLRD_sAr_HL1gCUzxPWjAK2f6efOatYJ8bruEZJyigkIG8Tl A82bCdvxWblpsexz8g1MLUzq4swoa8MuTvGfyj6SM8G9BeAG5ElP50SsTEwc4oEwqbXFsDfC4.g8 PTtF9VsSEqWirvRUOWpKPzX7vWN0vz3vI6wasPPAXgjeovYsQ5PV6gkz_lpYJXig9geigDhjoCL8 92Vc_inYumZ3Nvr.lhMeKYXkZCq85vKXcQL4THfuZVADXXA_7guuV1geCm4PjR.siyimeUcPiEz6 fEG7gQJwJaT99zkXYWs6yDCfWMJ_TgEBzERpTvWsE86G_DsQxvJY23.f9upWeu8XoxsSmTfbNCRX M035CvU4oD.DEBtm6Es1VJjnBz1IAiBdKHW_v9.1Ywi7wAQJEp2nqb2Kl2WaJip_RTq8sdfE25CL zfXX100yurIsNV7Dk9dlvgKlNd6JLSj3GBnFi0jdV8Qed4PO69qbipmXVHVBRADb60c6dOxeOUMl a_WpispK.3_FMEY0xBcos4aRbUlOueTg3bLnxVxzNbZCDLVSi85BIFtMLh38isfKmplB7Y2rxFCj 0HERfiTWXz7FAjc9tdUA7dWzSzhOy0aT3pGzRdmqELoM5NGODViCBQR6PYhz06vs6KEQIvdbkdtj vKGISucNHKzqwIa9DvRIazicG15p_FahrNhRkbc5ATdt_39.4a5oclqJjadzwv.lOiYdWNjmQpzG jXo7_YKKMCAnCQPqEJwcByo9mPLE1vSLz4f7nrbGTSE6SeMnJbiDSErPjrMVj1KhYdoa5tIYn5d5 DU5FkE8t8ugUw1GaG4ZjmYxfSToCECZp6FDxc0pFXOitNtFMV.F3ejYYyTauyrhk9Qi8r1VL1gWG hsG634ey6BrwvSpGwiG.16x8mET3BkblTIOzW3vjtzQkiAsq3DSWvaVslg8xpGEIipLzTs4FN.H_ 9GKZKSuBuX55MXG0PMc.R8ozuzA3wT9lS_IRUGKHXSBmRiRqTjnZvzeONbZBbnd7MbvrCs3wJ_jn RPhfCQUe8jBUBr1JJmgP9mNKjSTQPhOwB0bipC9A2flPcJ83_sxqtQeEdietc47QK2._nqQ9IKTV 5DNUJgyfwZ71M4ODPna.mwLhGZKojeJoOM2mOofnBWm6W_XIXj.wp0THS1G2x1yWL1Z1N X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Feb 2022 05:21:07 +0000 Received: by kubenode520.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b9751899b9bd999c8233374309fc5a4b; Tue, 15 Feb 2022 05:21:04 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Pi3 answers ssh only if outbound ping is running on -current From: Mark Millard In-Reply-To: <20220215034924.GA46139@www.zefox.net> Date: Mon, 14 Feb 2022 21:21:02 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> <20220215034924.GA46139@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JyTvt3Xlbz4lND X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=dKeCndzt; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5394 Lines: 138 On 2022-Feb-14, at 19:49, bob prohaska wrote: > On Sat, Feb 12, 2022 at 04:50:21PM -0800, Mark Millard wrote: >>=20 >> Recommended experiment . . . >>=20 >> Since I have a context working based on the kernel in: >>=20 >> = https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02= 8c372d4ac4f72b503/arm64/aarch64/kernel.txz >>=20 >> I recommend that you try that exact same kernel in your >> stable/13 context. I recommend renaming the existing >> /boot/kernel before expanding the kernel.txz into / and >> so causing a new /boot/kernel/ to be filled in. >>=20 >> If that makes things work after rebooting, then your >> kernel can be blamed. (More investigation to know more >> about what is going on in your kernel build.) >>=20 >=20 > Replacing first the kernel and then the dtb directory > didn't change the machine's response to incoming pings.=20 Intersting. > The stable/13 machine does answer ping sporadically during > boot, but falls silent once it's up to multi-user. Starting > an outbound ping seems to allow incoming pings to be answered, > but only very briefly. With inbound pings coming at 1 per=20 > second and outbound pings at 1 per ten seconds less than > ten percent of incoming pings get an answer.=20 >=20 > There's a superficially similar situation described in=20 > https://forums.freebsd.org/threads/strange-tunnel-behavior.27804/ > except that I'm not (knowingly) using any sort of tunnel, and in > my case single pings do occasionally get answered on their own. >=20 > The misbehavior in that case is attributed to packet filtering. > Near as I can tell it isn't present on my machine, with one=20 > hesitation: By default, FreeBSD supports DHCP, which I believe > once used bpf. I've never explicitly turned DHCP off, merely > commented out the ifconfig line in /etc/rc.conf and added an > ifconfig line to bring up a static address. Static addressing. Hmm. Could you configure an independent network with no router for a test, such as just an EtherNet cable between the 2 RPi*'s, no use of your normal network? (I've no clue what all this involves, if it is even possible. It would be good to know how to set up such a minimal-context test.) The point is to side step as much equipment as possible in order to see if something outside the RPi*'s is contributing. There may be a more reasonable approximation than the specifics I've suggested. > Is it possible there's a packet filter running in the background? > Perhaps under another, newer name? Besides the RPi*'s, what devices are processing the network packets? > There's no /dev/pf, but there > is a /dev/pfil, described as a packet filter interface. The man > page notes "In FreeBSD 13.0 the interface was significantly = rewritten." > The man page is dated January 28, 2019, so it's old news. >=20 > /etc/defaults/rc.conf contains ipfilter_enable=3D"NO", so it's > unclear why there's a /dev/pfil present at all. Perhaps via > some other service? Making sure packet filtering is turned > off seems like a good thing to try. Can't find a way to do > that via looking in /etc/defaults/rc.conf=20 Long ago I technically had an externally-static address but I still just used DHCP locally: The router had the static address but I'd set up to not expose the network. I'm not going to be any help with the things that you are referencing. >> But if the above does not make things work, that points >> to investigating alternate worlds from: >>=20 >> https://artifact.ci.freebsd.org/snapshot/stable-13/. . . >>=20 >> That is a messier context. I only do that with media that >=20 > Indeed, I'm not sure I'm up to that level of messing...... > It looks clear that mine is a local problem, doubtless self- > inflicted, most probably from using removable flash media as > swap. It'd be comforting to know for sure, of course. Part of the point of using a separate microsd card is to have an environment where blasting away the content and starting over is okay. I've been lucky for most of my testing: I could boot a fresh install and test without any significant configuration: defaults from installation were nearnly sufficient. But I've no clue if you could have that kind of test. Testing with defaults, instead of your normal configuration is also part of the point, sort of like avoiding other networking devices being involved. >> I can delete everything on, such as an independent microsd >> card: chflags -R noschg /mnt/ ; rm -fr /mnt/ ; various >> tar -xpf ???.txz -C /mnt/ commands --while not booted from >> the microsd card. Repeat for each snapshot tried. >=20 > At this point it's tempting to try the oldest stable/13 > kernel available on artifact.ci.freebsd.org, Well that would be when 13-CURRENT was first branched to make stable/13 and 14-CURRENT, before releng/13.0 existed. ( stable/13 predates releng/13.0 .) I'd not try a modern world going back that far: I'd also use an old world. Again, I suggest an independent media, such as a microsd card that is then separately booted and used for the testing. Well, 2 microsd cards so both systems are using defaults. > if that makes > no difference it's time to start with a fresh install image. I'd test such on separate media first. If it still has the problem, why destroy the original context and deal with the extra associated activity? =3D=3D=3D Mark Millard marklmi at yahoo.com