From nobody Tue Feb 15 03:49:24 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8A4F4194C09D for ; Tue, 15 Feb 2022 03:49:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyRsx4rFyz4bbV for ; Tue, 15 Feb 2022 03:49:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 21F3nP7M046197 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 14 Feb 2022 19:49:25 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 21F3nPV3046196; Mon, 14 Feb 2022 19:49:25 -0800 (PST) (envelope-from fbsd) Date: Mon, 14 Feb 2022 19:49:24 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Pi3 answers ssh only if outbound ping is running on -current Message-ID: <20220215034924.GA46139@www.zefox.net> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JyRsx4rFyz4bbV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.91 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3271 Lines: 77 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. 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. Is it possible there's a packet filter running in the background? Perhaps under another, newer name? 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 > 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. > 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, if that makes no difference it's time to start with a fresh install image. Thanks for reading, and all your help! bob prohaska