Relayd dropping packets - launching tcpdump solves the issue

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?

Hi @RPi

my only idea is that tcpdump will put interface in promiscuous mode
now, the question is, how promiscuous mode influence relayd ...

This could be an effect of the upstream router running a multicast querier. OpenWrt does this by default.

Could you please check if setting the allmulti flag on the interface facing the upstream router also helps?

ifconfig wlan0 allmulti

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.

I'm still curious as to "but why"?

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? Not even NAT or firewall?
That's crazy high.
Are you looking at the status screen and seeing 0.02 thinking that means 2%?

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.

Yeah, that is a Linux thing:
It shows overall load, since you have 4 cores divide by 4.

Or, another way to look at it: 4.0 is 100% load.
The Pi, real world performance numbers show that it can route and SQM gigabits of packets using 25% of its CPU capacity or so.

Also, if you don't know about it Network/ interfaces/ Global network options you can use Packet Steering and watch the load become zero.

I, really do, suggest the Pi be the main router when you plan on upgrading.

:spiral_notepad: Undervolting the CPU won't do as much as turning down the radios TX to only what is needed for stable throughput.

I'd swear I'd read the CPU controls the voltage but I can't find it and must have dreamt it.

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.

I've never tried it.

Nice yagi!
The rest looks very tidy too.

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.