Re: 60+% ping packet loss on Pi3 under -current and stable-13

From: bob prohaska <fbsd_at_www.zefox.net>
Date: Sat, 30 Apr 2022 18:11:25 -0700
On Fri, Apr 29, 2022 at 08:14:27PM -0700, Mark Millard wrote:
> On 2022-Apr-29, at 19:12, bob prohaska <fbsd_at_www.zefox.net> 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_at_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_at_pelorus:~ % 

and the -current machine reports: 
bob_at_www:~ % sysctl -a | grep -i model
      Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,1TB PA>
      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_at_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
Received on Sun May 01 2022 - 01:11:25 UTC

Original text of this message