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

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

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

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

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

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


===
Mark Millard
marklmi at yahoo.com