From nobody Wed Feb 16 23:18:26 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 343BC19BC7E1; Wed, 16 Feb 2022 23:18:28 +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 4JzYmM20r4z4SFh; Wed, 16 Feb 2022 23:18:27 +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 21GNIRcA055289 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 16 Feb 2022 15:18:27 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 21GNIQ4K055288; Wed, 16 Feb 2022 15:18:26 -0800 (PST) (envelope-from fbsd) Date: Wed, 16 Feb 2022 15:18:26 -0800 From: bob prohaska To: freebsd-net@freebsd.org Cc: Free BSD , bob prohaska Subject: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound ping is running on -current Message-ID: <20220216231826.GA54961@www.zefox.net> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> <20220215034924.GA46139@www.zefox.net> <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@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: 4JzYmM20r4z4SFh 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 [-1.10 / 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)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; 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: 2049 Lines: 56 [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. Thanks for reading, and any ideas! bob prohaska