Date: Mon, 14 Feb 2022 21:59:23 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Pi3 answers ssh only if outbound ping is running on -current Message-ID: <B186B406-233A-4765-9B1B-EB8136D01F2B@yahoo.com> In-Reply-To: <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> <F5FC2E50-C1E8-4E84-B4D4-DC7BFC3C9C14@yahoo.com> <20220215034924.GA46139@www.zefox.net> <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Feb-14, at 21:56, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Feb-14, at 21:21, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On 2022-Feb-14, at 19:49, bob prohaska <fbsd@www.zefox.net> 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 <kib@FreeBSD.org> 2021-10-19 = 21:25:19 +0000 > committer Konstantin Belousov <kib@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B186B406-233A-4765-9B1B-EB8136D01F2B>