doragasu

Yeah, also on my laptop (Arch with upstream 6.16 kernel) this problem does not happen, so it shouldn't be because of specific patches to the rtw88 kernel in the RPi kernel repo. It only happens when I use the kernel built with Armbian build system. I am completely clueless about what could be causing this 🤷‍♂️

@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...

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

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.

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!

Yeah, I noticed it was not rebuilt on the next calls to compile.sh. Might not solve the problem for CI/CD environments, but for development it should work. Thanks!

I am building a custom image for rpi4b and everything works great so far. I only want to customize the installed packets and configuration, but I do not need a custom kernel. Since building the kernel is what takes by a wide margin most of the image generation time, I was wondering if there's a way to build the image without building the kernel (using the one from the official builds). I have browsed the documentation and found no way, so maybe it is not supported and building the kernel is mandatory?

Thanks for help. If I understand correctly, that script is useful to add files to the image and perform modifications of it. But it seems that runs on a virtualized environment (QEMU I presume). Although that might work, I would prefer having a cross-compilation environment. I have verified the docker images I mentioned before have the cross compile toolchain, but I don't know if armbian generates something like a staging directory to be used for cross compilation. Could it be this is not possible with armbian and I should be using something like Yocto for this task?

I am new to armbian, and so far I managed to build a working image with some custom packages added and some removed by customizing `userpatches/lib.config`. Easy stuff and it's working great so far! Now I need to build some packages from sources and get them added to the resulting image. The usual way I would do this, would be installing a cross toolchain, having a staging dir with includes and libs from the dev packages I add to the image, etc. But after building the base armbian image, on my system I see I have two docker images related to armbian (ghcr.io/armbian/docker-armbian-build and armbian.local.only/armbian-build), and I wonder if maybe the "local only" image is somehow like a "staging" image or how does this work. So far I have not been able to find documentation about the procedure, is there any guide explaining how to achieve this?