Date: Mon, 14 Feb 2022 21:21:02 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Pi3 answers ssh only if outbound ping is running on -current Message-ID: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> In-Reply-To: <20220215034924.GA46139@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Feb-14, at 19:49, bob prohaska <fbsd@www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0>