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

On 2022-Feb-14, at 21:56, Mark Millard <[email protected]> wrote:

> On 2022-Feb-14, at 21:21, Mark Millard <[email protected]> wrote:
> 
>> On 2022-Feb-14, at 19:49, bob prohaska <[email protected]> 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.
> 
> I got that wrong: the artifacts history does not go back that
> far. Looking just now, I found:
> 
> author	Konstantin Belousov <[email protected]>	2021-10-19 21:25:19 +0000
> committer	Konstantin Belousov <[email protected]>	2021-10-26 02:26:27 +0000
> commit	485cc5549c3b383c6158bf47ac40c8002e276666 (patch)
> tree	162311b2a8e477f078823137491e30110671bd90
> parent	59447a02f1a9083f37d8e1e0d75bbb76ccb669d6 (diff)
> download	src-485cc5549c3b383c6158bf47ac40c8002e276666.tar.gz
> src-485cc5549c3b383c6158bf47ac40c8002e276666.zip
> 
> https://cgit.freebsd.org/src/commit/?h=stable/13&id=485cc5549c3b383c6158bf47ac40c8002e276666
> 
> but it might not last long as old is dropped (when new
> is added?). It looks to go back somewhat over a year.

Trying again: somewhat over 3 months.

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