Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound ping is running on -current

On 2022-Feb-16, at 15:18, bob prohaska <[email protected]> wrote:

> [changed subject to more clearly reflect the symptoms]
> 
> On Mon, Feb 14, 2022 at 09:59:23PM -0800, Mark Millard wrote:
>>>>>> 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.
>> 
> 
> It looks like the kernel isn't an obvious culprit: Versions
> from late October to a few days ago all behave the same way.
> 
> Even when booted single-user, with the ue0 device brought up
> by hand, only about 1% of incoming pings are answered. That
> figure rises to a little over 50% when there's an outgoing ping
> process (both running a 1/seccond). Destination of the ping
> does not seem to matter, an unused IP seems to work fine. 
> 
> AIUI, nothing of userland apart from a shell and the ping
> process will be running under those circumstances. Is this
> correct? 
> 
> Might the trouble be inherited from the boot files? I've left
> them alone since the machine does boot and updating them 
> isn't automated. Right now the machine boots from microSD
> and then runs bootcmd_usb0.
> 
> One oddity noticed during the kernel-swapping experiments
> is that at the loader prompt some kernel names don't seem
> to be recognized. If I type kernel or kernel.old it's
> loaded immediately. If I type kernel.no-bpf which is one
> I built, booted using the name kernel and then saved with
> the name kernel.no-bpf it can't be found, even though it's
> visible via ls at the OK prompt. Might - be a prohibited
> or priviledged character to the loader? Names like
> kernel.20220214 are likewise not recognized, even though
> they're visible using ls.
> 
> For lack of immediately better ideas I've started stress2
> running in single-user mode to see if anything of interest
> results.

I expect that this was your first message on the
issue to freebsd-net. So I'll reference your previous
notes on the behaviors that you are seeing that you
sent to freebsd-arm at the time:

https://lists.freebsd.org/archives/freebsd-arm/2022-February/000989.html
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001002.html

This might avoid some Q&A.

===
Mark Millard
marklmi at yahoo.com