From nobody Sun May 1 01:11:25 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 1DBC81AB8F7D; Sun, 1 May 2022 01:11:29 +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 4KrSq41Rcyz3J3L; Sun, 1 May 2022 01:11:28 +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 2411BQDA010919 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 30 Apr 2022 18:11:26 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 2411BQap010918; Sat, 30 Apr 2022 18:11:26 -0700 (PDT) (envelope-from fbsd) Date: Sat, 30 Apr 2022 18:11:25 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, bob prohaska Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13 Message-ID: <20220501011125.GC10723@www.zefox.net> References: <20220314010330.GA70447@www.zefox.net> <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com> <20220428023226.GA5666@www.zefox.net> <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com> <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com> <20220429005206.GA1171@www.zefox.net> <20220430021207.GA7600@www.zefox.net> 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: 4KrSq41Rcyz3J3L 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.03 / 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)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.917]; 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_MEDIUM(0.59)[0.587]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.54)[-0.537]; MLMMJ_DEST(0.00)[freebsd-net,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: 4483 Lines: 111 On Fri, Apr 29, 2022 at 08:14:27PM -0700, Mark Millard wrote: > On 2022-Apr-29, at 19:12, bob prohaska wrote: > > > Since about December of 2021 I've been noticing problems with > > wired network connectivity on a pair of raspberry pi 3 machines > > using wired network connections. One runs stable-13.1, the other > > runs -current, both are up to date as of a few days ago. > > Compared to your later notes about 192.168.1.n style use, > are any of the above that way? Or are the all well-analogous > to the "on the public network" context mentioned later? > Not sure I follow what you're getting at, could you clarify please? The move between public and private networks was done by changing comment delimiters in /etc/rc.conf and moving cables between public switch and private router. Only the two Pi3s have so far failed to answer pings and ssh connections after reboot. > > Essentially both machines fail to respond to inbound network > > connections via ssh or ping after reboot. If I get on the > > serial console and start an outbound ping to anywhere, both > > machines respond to incoming pings with about a 65% packet > > loss. Ssh connections are answered with delays of zero to > > perhaps thirty seconds. Once connected ssh is usable but > > erratic, with dropped characters, multi-second delays and > > disconnects after random intervals from minutes to hours. > > > > There are five other Raspberry Pi's on the network. Three > > Pi2's run 12.3-stable, one Pi2 runs -current > > RPi2 v1.2's used as aarch64? (So similar to RPi3*'s.) No, the Pi2s are v1.1. > RPi2 v1.1's (armv7)? Yes. > Which type of RPi3* variant? B? B+? Revision? > The stable/13 machine reports: bob@pelorus:~ % sysctl -a | grep model hw.model: ARM Cortex-A53 r0p4 hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837 hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2 dev.smscphy.0.%pnpinfo: oui=0x800f model=0xc rev=0x3 bob@pelorus:~ % and the -current machine reports: bob@www:~ % sysctl -a | grep -i model Memory Model Features 0 = Memory Model Features 1 = <8bit VMID> Memory Model Features 2 = <32bit CCIDX,48bit VA> hw.model: ARM Cortex-A53 r0p4 hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837 hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2 dev.smscphy.0.%pnpinfo: oui=0x800f model=0xc rev=0x3 bob@www:~ % That's slightly surprising, since they are of different age and one has WiFi, not sure which. I believe that makes one a B+ though I gather FreeBSD still doesn't support the on-board WiFi. Either way, I thought the wired ethernet setup was identical. > > and a Pi4 runs > > -current. All have no problems pinging one another and out > > of network, so there's nothing obviously wrong with the net. > > The network is not routed, but rather a block of eight > > addresses simply bridged from my ISP over DSL. > > > > It's been found that an image of 13.1-RC4 behaves similarly > > on one Pi3 when on the public network but exhibits more normal > > ping response when moved to a 192.168.1.n private network. Just to be clear, it was the same Pi3, I moved the cables and changed lines in /etc/rc.conf to make the switch. > > On the face of it, this seems significant, but I can't guess how. > > Did you try a RPi4B on the public network, booted using the > same 13.1-RC4 microsd card you used in the RPi3* testing? > (Modern aarch64 RPi* images should boot either type of > aarch64 RPI*.) > > If yes, what was the behavior like? Did it behave like the > RPi3*? > > If no, it should be a good test for how specific the problem > is to the RPi3* vs. RPi*'s more generally. > I haven't tried yet, since the Pi4 was on the private network to begin with and it has never had problems answering ping and ssh. AIUI the Pi4 ethernet is on PCIe, while the Pi3 uses USB. If the Pi4 failed to answer ping when running the snapshot I guess that would point to either faulty media or a different place in the network software. Perhaps worth a try. > Testing a EtherNet dongle known to use a different driver > could also be a form of cross check, if you happen to have > such available. My only alternative Ethernet adapter is a Ralink WiFi dongle. My WiFi is private-network only, and the snapshot worked reasonably well when wired on the private network. A wired adapter would be more informative, but I'll have to figure out what to order. Thanks for writing! bob prohaska