Re: Pi3 answers ssh only if outbound ping is running on -current

On Sat, Feb 12, 2022 at 04:50:21PM -0800, Mark Millard wrote:
> 
> Recommended experiment . . .
> 
> Since I have a context working based on the kernel in:
> 
> https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a028c372d4ac4f72b503/arm64/aarch64/kernel.txz
> 
> 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.
> 
> 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.)
> 

Replacing first the kernel  and then the dtb directory
didn't change the machine's response to incoming pings. 

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 
second  and outbound pings at 1 per ten seconds less than
ten percent of incoming pings get an answer. 

There's a superficially similar situation described in 
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.

The misbehavior in that case is attributed to packet filtering.
Near as I can tell it isn't present on my machine, with one 
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.

Is it possible there's a packet filter running in the background?
Perhaps under another, newer name? 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.

/etc/defaults/rc.conf contains ipfilter_enable="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 

> But if the above does not make things work, that points
> to investigating alternate worlds from:
> 
> https://artifact.ci.freebsd.org/snapshot/stable-13/. . .
> 
> That is a messier context. I only do that with media that

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.
 
> 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.

At this point it's tempting to try the oldest stable/13
kernel available on artifact.ci.freebsd.org, if that makes
no difference it's time to start with a fresh install image.
 
Thanks for reading, and all your help!

bob prohaska