Odd issue with relayd dropping packets on my wifi bridge. Router is built with a Raspberry Pi Compute Module 4, using onboard wifi (station) and USB wifi mt7921au (ap) running OpenWrt 23.05.2. The Raspberry Pi connects to another router and that router acts as DHCP for the devices connected to the Raspberry Pi ap. There are only 2 or 3 client devices connected to the Raspberry Pi ap. I require low latency and very limited packet loss for this connection - when too many packets are dropped the entire connection drops and I lose video, etc.
I used relayd to bridge the two wifi networks and it works fine except for the dropped packets every 10-15 seconds... While troubleshooting the issue I ran tcpdump on the station side and lo-and-behold the issue immediately resolved itself as long as tcpdump is running. If the packets are being observed... everything works perfectly. If I stop observing the packets with tcpdump, it starts dropping packets again. I'm able to replicate this behavior consistently.
I've had to launch tcpdump at startup as a temporary solution. What could be causing this?
Yup, that's it - putting the adapter in promiscuous mode causes the packets to no longer be dropped. I added "ifconfig promisc" to rc.local so it persists after a reboot since setting it in Luci didn't seem to take. I much prefer this as a band-aid as opposed to using 10% of my cpu on tcpdump.
Hi, thanks for your response. I tried ifconfig allmulti and there was no change unfortunately. Double checked with it on/off after reboot etc. Putting the adapter in promiscuous mode did work though so I have somewhat of a solution. The Raspberry pi is really only using ~2% cpu, keeping it in promiscuous mode doesn't hurt anything I guess and it's easily implemented.
No SQM, there is NAT and Firewall on the ethernet ports - but you're right, looking at luci-statistics it's more realistic to say .5% average cpu usage with some spikes up to 2%. Not working hard at all, I think I'm going to underclock it to conserve battery.
Thanks for the info. I always found that to be difficult to interpret.
Packet steering is on, thanks. I am definitely a fan of it. What are your thoughts regarding irqbalance?
I ran a Pi 4B as my main router for a couple years along with a pi-hole on another 4B that has a wifi 6e AP. Had a bit of help getting there too. I'm in love with the platform.
About turning down the radios... great advice although this project is a wifi extender for drones so I'm running just 20dB out of the onboard wifi but it's connected to a 4 watt amp and a directional antenna. It uses the 2nd radio as the AP for the phone/controller to connect to. It has to transmit live 720-1080p video along with controls and have low latency over a significant distance so it's only 65Mbps at 20mhz channel width. The documentation regarding the drone's onboard Broadcom wifi has been good reading also.
Thank you, the pcb yagi is supposedly 12dB, I'll see how well it functions in outdoor tests very soon. It may be too narrow of a beam for this application. I have an Alfa 10dB patch antenna and a 6dB FPV moxon patch antenna to try if it doesn't work.
Undervolting the CPU won't do as much as turning down the radios TX to only what is needed for stable throughput.