Re: Pi3 answers ssh only if outbound ping is running on -current
Date: Tue, 15 Feb 2022 05:56:28 UTC
On 2022-Feb-14, at 21:21, Mark Millard <marklmi@yahoo.com> wrote: > 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. I got that wrong: the artifacts history does not go back that far. Looking just now, I found: author Konstantin Belousov <kib@FreeBSD.org> 2021-10-19 21:25:19 +0000 committer Konstantin Belousov <kib@FreeBSD.org> 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. > 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