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

On 2022-Feb-17, at 00:02, Mark Millard <[email protected]> wrote:

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

There might be a name length restriction on the directory
name that contains the kernel files? I know I used to have
problems on old PowerMacs and got in the habit of using
only short names. (So I've not challenged the assumption
in a long time.)

>> For lack of immediately better ideas I've started stress2
>> running in single-user mode to see if anything of interest
>> results.

The following are now available for experiments with microsd
card boot media for testing:

main [so: 14]:

http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220224-45c23c2608e-253384.img.xz

stable/13 as 13.1-PRERELEASE (no releng/13.1 branch yet):

http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.1/FreeBSD-13.1-PRERELEASE-arm64-aarch64-RPI-20220224-9134a398506-249729.img.xz

Can you repeat the problem with either of these as your boot media
content? Which one(s)?

===
Mark Millard
marklmi at yahoo.com