From nobody Tue Feb 15 05:59:23 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 58DC619C3D48 for ; Tue, 15 Feb 2022 05:59:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4JyVm92zKnz4pkR for ; Tue, 15 Feb 2022 05:59:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904770; bh=unaom/DynDZRFsKTic1XWSqunhgZ0yLn6p6pkTLE9tA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gS41CaEgvdA9hPqMlizQWXGXwqN7ZPU26LHN4AUpXf3tPjUqrK0v+j1t9PLvXUENawT6/so/BgxiDIglSIUTIKZ9G1duocQuWdvrgUfgv5cXHoBooQq7ih8iPL3Es3zyoNHNm8jxJdhymKxL8S6c+PHjBLrqDwwgXOU/hheFaP0WLU8xmm55Th79us9CaQNLlOKSmYJGimK8g1ee8YOFUIrjZGjS9QQ5gY1oPZ/SmsTZk6oviJgrfcofXFTIA7BDDZDaItWy45fJ+74iUCVyFVIsj0x7apzoX620Q/3EzmecpEvmy4DsGHA3bCHrObW1SAMSOeKz1MxNY4MkVT2sYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904770; bh=kkJlA5tLhFMaUtnOaYh2B8vgouYLnGvaG5uKZmdqbgJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e+IDUVe2Iz92b5mHzdtKKVaUhjQxhmk/GzLjVRuDKNlYdWCuLe1m0fYnb6aCDyP5XjW66NGFBI+RDOnN/lCZ2xSx7PexUtXMlizRsEizhG/Qy97+5/7IEQy7TsoMTHkRxIxAMazunO5FWBTt4wo7R6+hzOXo5ACITzwKNh9JrbCZbOt4Je+8SHAk+SIpfrLf6iIYycYpTtJUxHLRfQ/sGInQmEDA4bZnMZJZT0HF9oBWWIA1qN0ZgbfYdaJil7vMcOcZKLdFOM2sYulSvg9wD+jcw1d6l51A3ixTBm+OiBpeFmEaY3um59OK0GHIqL0/i28E2DqE2SZXD5nA2ihZwg== X-YMail-OSG: DghqqXMVM1nJ4KWJO6C4LXy0zlfaxSqC5hGlafjZ0JOZVmjXY74zEDApr0eb05P KeImwSZ0RPDd0EPev.zT5IfDAFFvro4RUlbMh5xdEsTUkUqLJnLecQLDMl34GmJ8voBQrkKzJ2mO mRXIEwg3fRkd.JkmUZNPVCV00h8qX4RdcGeLJK2jd0n6KLDi6nMJZr2SoVxmSuR90AuqK_bd3W6v jYUufwPunaxTGKRy.ZhYBri3HdNMifxGa6HqFr6GQ8RT2jLyJQ_x.NSqUHI2hDrRXl89xLgLsaR6 oWcXDrVEoT6ShyR9vRuk9lAOMBcfXv3uc_.soHUNKg_OXrdfYw1KbPOZ8KMJtXL.cFGcfqqSs2kb iOYRzFwCiuZ5pt1IxtjDfY07yX5MW2B7Gsis8m.KQWsT7j1S8IbAijUaLQn_Jhe4W9_Rt8UpPRYh OZlDPE5KSmqUohpbC9FG4q1ot73EU27J7jAKjPPdLEj4WoIi_fEIJf31HlXyD872AVWUIKVX0p85 IuyP2ApNrT5.X.y4.Dh.HP3zQGCDHeHpdvy8JtvirrJshCjZSN81IuGeDIb8vELxka13m54KESN2 xYotXEh_b.iFSbyUhv.Gbs1tT_Omc0hMGf5syYZjNG90rroCqjdY2BTpG6OI5AgBkimhOun.Q_tl iuTfZ3ATQiVml.CzzYoNTyC7UWIFI_OUnJYnLJSyRY58BMvDGkEDnVViYYtmn6InjTUL4apfXDS1 htaYNhN2EOGXwOqjgb5YQ3YbB7vbTG.hek6mNv1bKOfGixMIP385SQwTlYzPdYH1mZc3tbR29Ddo _HfSwVmNXQkGB86qXpOvAcnkx9N9Wy82NNFG9OMm6dJcpS5495Ry_VKNVf9TEc38LDW4qdQWAaL9 SjPz3SLrQO1hlSwQkk0ZRXtDbNGTVlQTmjkfPdZ3fX_tBj7em5IrgRYGZbce4fhSr2LrEqEMJT30 RO5DlNOHkDftk2SVm4f2nePv5GmmxIRV4Z4rX1ZDoqhAFhpjn9HkTwy9Zx7PEmIk0YB2TcWVM8mT bVbuUKM6shx5c63snxzErpLP9aK2tAwYPakJJ8rSvR_hbywVU2q794xFLKBGAINFxVnKA23At2M1 vQB4Q4WC6QutxtfXpK8RM83UpV303K0d4sztWra4hknYok1y6E7vxoJnuvivvCV4jA6l2UbBXijV ylrKnzlEWVZ0ynEw_0pvARfTXXXpuF2PnJ7wJgzKKwdxzQ27lorem3iCMa1CUACOUW2I3ksrh8_W o8Vj_HMoiM1vmE0PPpH8wGSY.MbOfGHypXCr2zGzB_kLzOAos3LQWHCQCiqXuMWvSyOUE1bTE2iR _97Q5MqAUeCLqNEuXPqyIYGRzK_8yNm1Mfe3QWHiPN5diMBb0_MlPAc_pGaAhvViD9nWZ0hXLJPc jtQxaJXbTT79f75h4iP_fIo26LSTz6aw7B.zSXEUT6stNHiHpENxaRLJkhIcZfBygXuFC7FyrfOM DgU9K7qqMEVFvhYC0otg2OpGUkPPEBSO4_FhGk37SsvntUnJ4CT6HYfrzJ4r5bNOtOWxLOfr6FoY qiCtgZG7qIwwm0FUtHvjil1QE_41EAyBV5wughtWnYnzTIdtSyRW7K8eB0Lp9xggQq2YAydnoh9u qZcT1EPrJTZa.m7v6BnZy1lZaDRQ.WAcuw6iyDpQ5ehxI8qZXtPC2PyZxdhbWPAQT1WJ7XqgEFfa XXYPl7h_fc0M6UHl1.uxd30gCCvRMna2mCiRAXlNKJ6hSnAl9Jc2tlT4GCsMGATg7JnAIQqYneZj I5u8kSWTvyS2khktPa.w23fhDPr2M_T6Q13mM7lxGuADbmIXx9IGP8Fpjv4bDGyweZE9sG3fdfMv rG8LS8X1UvkJ1cFuWaStlePx4E.M0HI3PAtMsBu0vdjzMS5TYoXCFxzIYQIBcIwBf.O841aevqfd 3_cpdAV7zO.Q7pLFlvxve50hWa8vgutRFMQBnEv0nsVm3L5Mho1OrZjQ8siSn.nrn6hD8oVfmqQs _ontrLZH..RDhob9rwsTiIleVGwdtqodT_RUgK4JwkAgqmuSokyv1PNSQCK4fsW.MMvZijDfUWPO nEGPVBoS.xV9fuBAhzlK2Le7IR3FCOTcjeVnj5Ky9Nhq_M3DSVobBvtnNFQjB9b105v.TqoQCX7e SDZK2iy2fOvhowOBi51LpwTn0NC6A6Asq4EcQQ5hCt0ftHY5Ev8Z4GREQFyGznBCjooR0Pbyf4If eUmJK05TgTgKaXFaW0uhi9W3YxTrHx2DsxCoDc5wA6plD78HJI8HYD7GDBnKvTm9mPSvqUYnFDpl 6ThsARNs7poYldaORh7brK6yhxUmR4QJcdYKAtXDBq0tpeLYsVZf4E8pt4QIWX9v.I9RU6ArkMw- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Feb 2022 05:59:30 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a5e37becaa31f5ae61b4c0740a8f335f; Tue, 15 Feb 2022 05:59:25 +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: <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com> Date: Mon, 14 Feb 2022 21:59:23 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: 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> <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JyVm92zKnz4pkR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gS41CaEg; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 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.65.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6700 Lines: 169 On 2022-Feb-14, at 21:56, Mark Millard wrote: > On 2022-Feb-14, at 21:21, Mark Millard wrote: >=20 >> 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. >=20 > I got that wrong: the artifacts history does not go back that > far. Looking just now, I found: >=20 > 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 >=20 > = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D485cc5549c3b383c61= 58bf47ac40c8002e276666 >=20 > but it might not last long as old is dropped (when new > is added?). It looks to go back somewhat over a year. Trying again: somewhat over 3 months. >> 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? >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com