Poor WiFi monitoring performance with RT8821CU

[doragasu]

I am currently developing an application that requires using monitor mode with RT8821CU chipset (rtw88 kernel driver). Previously I was using RaspberryPi OS and everything worked great, but I am moving to Armbian mainly to be able to target more SBCs. The problem is in Armbian, the WiFi monitoring performance is much much worse (at least with the RT8821CU) than with RaspberryPi OS and with my Arch laptop, and I cannot guess why could this be. I have tested on the rpi4b the following:

 

* Build the rtw88 driver with debug and debugfs enabled just in case.

* Test with all the three kernel versions available (edge 6.16, current 6.12, legacy 6.6). None of them achieves decent performance.

* Test the 8821cu driver (**a different driver than the rtw88**): seems to have better perf, but doesnt support the fcsfail feature I need and is quite unstable (for example creating a new interface on the device phy using iw, causes the system to freeze and requires a hard reset, and on some circumstances, calling iwconfig also freezes the system).

* Try all of the above on the community supported OrangePi 3 LTS: same result, I have the same poor WiFi monitoring performance as with the rpi4b

* Cross compile the Raspberry Pi kernel myself (I tried with version 6.6) with rtw88 driver enabled, and manually install it in my rpi4b Armbian SD card (copy the kernel, dtb files and modules, and create appropriate symlinks): I get the same perf as in Raspberry Pi OS!

 

So there must be something with the kernel built with Armbian that is causing this monitoring performance degradation. Unfortunately I am clueless about what could be causing the problem. I have reviewed the kernel configuration, and all options related to the RTW88 driver are the same. But there must be something elsewhere that I cannot find.

 

Any suggestion about what could be the problem or how to debug it? Thanks in advance!

Edited yesterday at 01:56 PM by doragasu

[doragasu]

After a lot more experimentation, I have noticed the frames I am missing are the 802.11b ones! So something must be disabling these on Armbian. Unfortunately I cannot find what.

[laibsch]

kudos for your perseverance.  and thank you for sharing your findings.  I hope you will be able to work it out eventually.

[c0rnelius]

Run a diff on the pi and armbian defconfig.

https://github.com/raspberrypi/linux/tree/rpi-6.12.y/arch/arm64/configs

 

[doragasu]

OK, I made a really ugly script that sets managed mode, forces 1M legacy mode, switches back to monitor mode, and then performance is exactly as it should. But the thing is, can this be avoided? What could be causing this behaviour on Armbian, and how to avoid it?

 

This is the horrible workaround BTW:

 

#!/usr/bin/env bash
set -euo pipefail

ip link set mon1 down
iwconfig mon1 mode managed
ip link set mon1 up
iwconfig mon1 rate 1M fixed
ip link set mon1 down
iwconfig mon1 mode monitor
ip link set mon1 up
iwconfig mon1 channel 1

 

[doragasu]

@c0rnelius: I already did a diff, but there are a whole lot of differences. In fact one of the things I also tried, was directly copying the .config file I use to build the RaspberryPi kernel to the config/kernel/linux-bcm2711-current.config and build that kernel, but I got exactly the same result.

 

What I have not tried and might do at some point, is doing a diff on the rtw88 driver sources. But seeing how forcing the 11b mode as described above workarounds the issue, I suspect it might be some kind of config issue causing the 11b modes to be disabled somehow...

[c0rnelius]

I don't see anything in the history that would suggest they made any changes? I could submit a RTW88 patch I put together from the lwfinger/rtw88 repo. But seeing as the pi guys haven't appeared to have changed anything on their end, it is probs more trouble than it is worth.

 

[c0rnelius]

15 minutes ago, c0rnelius said:

I could submit a RTW88 patch I put together from the lwfinger/rtw88 repo. But seeing as the pi guys haven't appeared to have changed anything on their end, it is probs more trouble than it is worth.

 

Plus the kernel source is getting pulled from their repo. If they did make a change, you should see it on Armbian.