From nobody Tue Feb 15 05:56:28 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 02A0519C3095 for ; Tue, 15 Feb 2022 05:56:36 +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 4JyVhf60mlz4p6P for ; Tue, 15 Feb 2022 05:56:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904592; bh=2oPLYfHDtCoxWAD06hCdm6XJ21Sy72aflt3+z/xK7ng=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CvJ2aIEx9Qxd7YTHARdiLtR6UrdvAEoksWQe0KH9sVrZqYy2JgFWKZ7UdTLzqjdVERykeQ+FHs90NFJdjLPVKzvUCEUtm0Td7hWIiNPX5ZV9H94cA4IXpbuFkaKUcMROroxjTddY7mMPCe4qaliC7QjDhcSSsmxl+L1cllanoI4jzUYxD9yfPVqXAoOBjU/R8tzbLsixDrlTrH2bPOQVlTOTGSirGzlU9F8tZg+jg0QirgtER9o9gzAb47kH7dkmyUFRNYNIhlZjfOXDCuOMI945H6w3/aPlFe1PXl77KlvQ5v3/nIWhlbtRCNTJUNOJYmDzjCzxdiiz+QpM5Jq7Nw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904592; bh=Q1ri8vGIXHBbRNyCqMX6x1oN40DksZqqINdj7LGeaAl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=J1Mj2Lsfkp+D+EjIhIHGFFwyDjBnPiMnC9d04KyI1fQL40WLLAz+ZomajBWv8Q/T+9c2Y61lwA/DYK9se8Ub9qasxGnU+m4TiJHood1C6Slhn7vgSSlFEHMeKOGD76wgiWvv2jMokz38Scd32HnpiA7+slAYC+BSPPsE9L9cJ+8kMZJI6eMU1lN/yzBqe2vorWNlMJCYvidyvVnyXPz8qLhkjtegzeQ/9BXuFPr3A+Ul3dekOfrfY7gX3jb1uX/2IrgynwQ84zbOdpxIPJOEOTaOd0JrtOn13vHCSYzrqDQyMNL+ZR0nDnM8Y54+YL+VP0vBZPsfECYUI7PeeGOSPw== X-YMail-OSG: yEbSgvgVM1nhOzCNAPg7xm62dZtTR2E7bTjxOcXSF4a6AeJMcWg_i0P2JAXfPFv nsxvgXyu38Kq_r3rlB60jS3SEkA0br4P1YAv5jCfZSowaNI8.imKK_UyiD6xKf5yWxHmtp_P5tZ5 Rzp7zeQ.HcIU4fnLKOSGbAnFUJXyhwgcrxM30_IwKBJWfphLte2Qp6oZ.iIFGoZZxTF4MnVFvxD3 Lp60PQy91dL4caG0Eo6HTry4BjISSVT_wsbm6hBDw39ddvtFUWJsdMcKSLejyCq_PJ_nWL1Gw7ku B0t_5n.FGwEhlHeoksvh3PNnZq.nHW0tXil3i56qhLjtmIHuQeU0Cm0zTkviCuU81oU3eXabDFbD Ylh_IPtqRPh_XJYwED8mweBmAzvH26HmdSVZa166Q4gux3v6ziY3_DCO.DOKc1vzsVPrLWg6etgN k4gky4.8VG5uKn1FW4ykmG3csZNlzGa94kQDMEfXMq.EIlmXr6j73T2kwYHh6t6CG2uqvkim2KfN Xx_.yZijNUeQJaKQ1I1iBkWQ3wRXSOfxo45pOw6nqaAWUNJ__8DQ1v5PhHzz89W6S9SDpzGjNaEQ nFmiHGeO.9pBOTA0FZn3sxcF6cDvyJZfa9hV1P_XRVlyHmNGu82jWjjgt2v1RouWly6EC65dknXw NB0rleZJtXONI7CnKJYOAKHLdvCkSu_htQwnFCbVMzrnaxVBhAZw2GD94kjwwpewr9nneQkzudPk pkO5UU2bxhRsIGpNmQFuOFS_lbf_egQm042JhrEpICdHfOPfmHj1EEzY1qClKxnxLuq22uuctNW8 q.SmBeOTHbvIai5uYsFzxfvLcT.dy3G1ZQSlGX4x32XcK7fLKzPJXYP72I27q1zPDyVFh04G8g51 ZV3YR1nwZO_o94M1_y2INM77e2RmsH0zM6Cac8RjG6pv2Zv2iUK3RQ1lQwxhipwD01MgRx3uZga8 9Vv6myFlCoYG5TKuS6eMLXAtOQgee3cdGmigAm6ibtOCjW_zYdrJfSUUhMHKEAR_TnbiL1aQKX8z VyhCmsICF70E2gPBov7WITpN3P6j4vWi1ouG0t2TihuPXpAUpgaLQRl63oc0CeK9rbiyurEsde_l xRZ29PtQBRJOQUXMAC6Hd6ayfDVMhnvWopQ1J40Ewipbl3otWWGLC1juKqVC1pt59XdCBY9Fq.s3 .6ub.JI9W_7HRuVvTBHkCQ49d8YsY7Tky3Gxz9e63SO2wufSnwEPqFIUXWi0s8.OrwUwIRvCdgpp W0vWkPYgv36ZlKDt_a8OBMRbumaXM__byGpd5lEoumbXdZmCALzlXXkQ81mj7Rc.SCtZqS7zK3Uy kn6Ddn87BFEQCdFPcxPhnEJSe962Ngn7auIN5LXCqlS3iRlXROy4N9jrntjEB6aDw7Ik2VqeoM3f mrcrDDx6zfRXRjP9L0a5tkEItKSWbYYxrrVX3xpYpj8vmzASRRY9JhI0UdtH_EyotctTRxu6L8q3 GWXxUK84EtcU.ovHWHPJyAmx7FOlxcWLzSm6VC9ZbvXSiUYGl3wKUfP_xMkNxb0RqIYBIT8kouer O5own802uYRd6ihi2AEJaQMoDHuRb_KDKN09AaYyIv1JpGDQdp63.IEJ5uAhLoOraaI67NzFl3tT kzwVxYg7xQyobaOVtvdnCjr3N5AqeVd_v9hItCLrDYG5xKVV4Xvdvb5utt.GF7CxhqyvsMWoB1HI ej02qmUOb785Wel4BewrZOhhYctVvwLiXcgSbeb5FSH845UJ6CBKaBsfivltWQWwi0JONtNAEvNl Ifyo5abLC1qvwZufFAeNmvyYfYccsaWpthBQtDMdYGxiP9i94GgN5a_Oe7jCdIBsCn4AG9BHl8Au .hZhftUZAiOLst132igrxqfCp4CqlNGvMOvi6rLB0BBENCDVzmfi425XJJav.Mh_t5_vMtGRQWjp 3kG8BB0idHk.mrEYbn4CX04CJxW41m5Cpkpdf2YCZIyJzYljOx9_V38LdiUIJsySYbnd_EkkXe79 vhQvORfH4NnawOIq0bk3esjJRPHbBzILL8lJaS9BJB6R.U_83rn3Hd092p_JPpgTDrFanzpbIJwx 3FI9RxCE4lkkAHmN1nM3gizdjxI8m8SC11UGLrAum_IYFtA.QxgUPFCZA7O5yobxJ1bxfaw2lDyP 1LtkEipTcf1L57GHyLgJBl62yHJ6Chq1wtEV_9C3ItSmjBrf.PwxvW5E2OTyzS9P_wLuTfBCb3vb stsCezEPgc63HZhBkp5YxTbcqFu1TlG8IazyyDpHuC9P9_7d6D8fBehkVVCKcSNlnpLc3nye.25V XOvKv6yENJZBAkx9frH_ovMZMaPKg2InvFg51wqHGNAzGLqccGOYMBUy4vAT52OJElsCEdQ4l 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:56:32 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5d0b2449b0876b67e509121cd7f14a4c; Tue, 15 Feb 2022 05:56:30 +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: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> Date: Mon, 14 Feb 2022 21:56:28 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> <20220215034924.GA46139@www.zefox.net> <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JyVhf60mlz4p6P X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CvJ2aIEx; 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]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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 On 2022-Feb-14, at 21:21, Mark Millard wrote: > On 2022-Feb-14, at 19:49, bob prohaska wrote: >=20 >> 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 >=20 > Intersting. >=20 >> 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. >=20 > 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.) >=20 > 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. >=20 >> Is it possible there's a packet filter running in the background? >> Perhaps under another, newer name? >=20 > Besides the RPi*'s, what devices are processing the > network packets? >=20 >> 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 >=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. >=20 > I'm not going to be any help with the things that you > are referencing. >=20 >>> 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. >=20 > 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. >=20 > 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. >=20 > Testing with defaults, instead of your normal configuration > is also part of the point, sort of like avoiding other > networking devices being involved. >=20 >>> 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, >=20 > 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. I got that wrong: the artifacts history does not go back that far. Looking just now, I found: author Konstantin Belousov 2021-10-19 21:25:19 = +0000 committer Konstantin Belousov 2021-10-26 = 02:26:27 +0000 commit 485cc5549c3b383c6158bf47ac40c8002e276666 (patch) tree 162311b2a8e477f078823137491e30110671bd90 parent 59447a02f1a9083f37d8e1e0d75bbb76ccb669d6 (diff) download src-485cc5549c3b383c6158bf47ac40c8002e276666.tar.gz src-485cc5549c3b383c6158bf47ac40c8002e276666.zip = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D485cc5549c3b383c61= 58bf47ac40c8002e276666 but it might not last long as old is dropped (when new is added?). It looks to go back somewhat over a year. > 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. >=20 >> if that makes >> no difference it's time to start with a fresh install image. >=20 > 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