More on the search for the mafic spell

I've set up Pi2s3s4s as 'servers' before, it was never THIS complex however. A PI is just a very small Linux box. Alas if you need multiple net ports you may need to think of USB dongles.

Oh, 'nmcli' ... if you have to add THIS much junk faster to manually edit the config file. Actually I posted instructions on that about a year+ ago. The NM GUI app is fairly capable too, IF you have a GUI on yer PI. Not all do, hence my post.

Net/USB/WiFi speed ratings for PIs are almost always "best case" ... actually they're kinda LIES. The P4 was much better, P5s even better, but it's not gonna be like a PCI card plugged into your Big Box.

WiFi is finniky as all hell. Recently had a PI getting a super-crappy signal, tons of dropped packets - moved it FOUR inches, no obvious obstacles involved, and now have a 4X or 5X speed increase and almost never a dropped packet. Note 2ghz tends to be more forgiving than 5ghz - 'slower' CAN be faster in some circumstances.

DO check to see if your DNS and router base address are correct. I had to get a new router and all my clients were still pointed at the old base address. They'd (usually) work OK on the LAN, but you could not get updates or any other internet stuff.

/etc/dhcpcd is the place to start. Also use NM to look at all those device defs. Tweaking those things fixed MY internet problems. Just ONE number mal-typed, ONE mistaken, number is enough to screw up everything.

..

As my job used to be in networking, of course I checked all that before posting

The PI is not acting as a DHCP server, Merely as a bridge. The router does all that (DHCP) and assigns the DNS servers etc.

I can ping an external *IP address* from the PI faultlessly.

I can't ping an external IP address from a wifi connected client consistntly I CAN ping an internal *IP address* from a wifi connected client flawlessly.

No, it isn't., Its not involved

Done all that already. That's why I published the nm files. So you could check.

E,g. here are some ping results This is from the Pi itself ...

root@Coriolanus:~# ping vps.templar.co.uk PING vps.templar.co.uk (185.113.128.151) 56(84) bytes of data.

64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=1 ttl=59 time=21.0 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=2 ttl=59 time=21.0 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=3 ttl=59 time=21.3 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=4 ttl=59 time=21.3 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=5 ttl=59 time=21.3 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=6 ttl=59 time=20.8 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=7 ttl=59 time=20.9 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=8 ttl=59 time=21.0 ms 64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=9 ttl=59 time=21.3 ms ^C

--- vps.templar.co.uk ping statistics ---

9 packets transmitted, 9 received, 0% packet loss, time 8010ms rtt min/avg/max/mdev = 20.788/21.093/21.302/0.192 ms

Now from a laptop connctred vuas the pi as a wifi access point

root@Prospero:~# ping vps.templar.co.uk PING vps.templar.co.uk (185.113.128.151) 56(84) bytes of data.

64 bytes from vps.templar.co.uk (185.113.128.151): icmp_seq=3 ttl=59 time=112 ms ^C

--- vps.templar.co.uk ping statistics ---

14 packets transmitted, 1 received, 92.8571% packet loss, time 13351ms rtt min/avg/max/mdev = 111.730/111.730/111.730/0.000 ms

But pinging the main server on the LAN is this

root@Prospero:~# ping 192.168.0.100 PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.

64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=12.4 ms 64 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=9.96 ms 64 bytes from 192.168.0.100: icmp_seq=3 ttl=64 time=11.3 ms 64 bytes from 192.168.0.100: icmp_seq=4 ttl=64 time=8.69 ms 64 bytes from 192.168.0.100: icmp_seq=5 ttl=64 time=10.2 ms 64 bytes from 192.168.0.100: icmp_seq=6 ttl=64 time=8.30 ms 64 bytes from 192.168.0.100: icmp_seq=7 ttl=64 time=11.9 ms 64 bytes from 192.168.0.100: icmp_seq=8 ttl=64 time=5.13 ms 64 bytes from 192.168.0.100: icmp_seq=10 ttl=64 time=11.7 ms ^C

--- 192.168.0.100 ping statistics ---

10 packets transmitted, 9 received, 10% packet loss, time 9021ms rtt min/avg/max/mdev = 5.127/9.950/12.386/2.163 ms root@Prospero:~#

I am beginning to think that whilst a theoretical possibility, wifi bridging on a PI is probably too s*it to use.

Have you read this? (Probably you have)

It applies to a debian configuration that is not what I have. I have no brctl for example. And it says *how* to set up a bridge,m but that I have already done.

It has no info on using network manager for example,

I am chasing a performance issue now - and a strange one at that.

Unless you can conclusively state that the bridge set up by brctl is markedly different from the one set up by Network manager, that 'how to' is not relevant, sadly.

The 'magic spell' I ended up using is pretty much this one

What is happening is that the bridge seems perfectly stable from Ethernet to the bridge host machine, but is very variable on the Wi-Fi interface, and that gets worse if

- the incoming packet is via the inbound router from the internet...

- inbound traffic to the host is heavy.

I get between 48% and 988% packet loss to external machines on the Internet. Mostly OK access to the rest of the LAN using the Wi-Fi interface.

Somewhere the bridge is dropping stuff and I don't know why. After struggling with journalctl there is nothing relevant in the logs that I found.

neither CPU nor ram on the Pi are especially overloaded.

In short according to the logs etc. everything is working as it should, but packets are being mangled somewhere.

I included my network manager files in case someone with a pi 4 or 5 might care to try and duplicate the setup and see if its s*it for them as well...

Maybe you need to find a mafician ...

A wave of the mand ?

What he describes is the normal way to set up bridging between multiple network devices (in this case ethernet and wifi) under Linux. A WIFI access point usually works as a bridge, so this *is* required.

Also, there is a difference between "client" WIFI chips and "accespoint" wifi chips, regarding features and performance. Most client cards nowadays have some kind of limited access point mode, but is limited compared to a real access point (number of streams, number of simultaneous client and other WIFI features).

I believe the raspberry pi wifi devices are more in the "client" category.

However, while the observed performance may be due to hardware limits, I would expect better stability with only one client attached.

cu Michael

Could this be caused by WIFI power management? You might try disabling that.

iw wlan0 set power_save off

or

cu Michael

already done.