MT76 issues with monitor mode

Well, remembering things like this and by doing several tests with Mediatek WiFi 6 devices, I am pretty sure that there is an issue with monitor mode (specially with WiFi 6 chipsets).

Most of my tests have been done in Banana PI R3 and Archer AX23 v1.20, OpenWRT 23.05.3.

The R3 as I said in the past, just simply breaks while you do an upstream speedtest with a monitor interface active. In other hand, mt7921 seems to do it better, you can be using the device for hours or a couple of days with a monitor interface active since the load average starts to raise without control, disabling all the WiFi functionality (no device can stay associated).

I have found that if you restart the driver and wifi the system recovers, the load average goes down and then you have maybe some days until needing to do this again. The commands to achieve this are:

wifi down
sleep 5
rmmod mt76
rmmod mt76_connac_lib
rmmod mt7915e
sleep 5
modprobe mt76
modprobe mt76_connac_lib
modprobe mt7915e
sleep 5
wifi up

So, I am pretty sure that there is an issue with the driver.

It would be valuable if someone who uses interfaces in monitor mode comments on their experience. I would be surprised if there is absolutely no one going through the same thing.

Additionally, I do not know if the issue has been addressed in subsequent versions of OpenWRT or if there is any line of work on the matter (I am not really finding any reference to this issue).

Thanks in advance for reading me.

Pablo.

Ever wondered ñbout purpose if airmon-ng?

Hi! Could you explain how airmon-ng (userspace software, which I clarify is NOT installed for any of the tests) would be coupled with this problem?

I use airmon-ng but in other contexts that have nothing to do with this point.

I'm talking about this issue occurring simply by having the monitor mode interface turned on (even without using it with some userspace application). If you have a BananaPi R3 you can simply turn on one monitor interface and perform a speedtest via WiFi to reproduce the issue. Nothing more needed.

I would like to take this opportunity to clarify that all my tests have always been focused on 5 GHz, so I am not sure yet if at 2.4 GHz the problem is also real or not (I will be doing more tests and getting more precise information soon).

Monitor mode does not work well together with others. Tool i mention exactly kills kinds of networkmanagets to have it stable.

Monitor mode does not work well together with others

That's a fact that could be relatively true in the world of end user devices, with chipsets intended to be WiFi clients and not APs.

The reality is that if the capabilities of the chip/driver support it, any combination declared in the capabilities should work correctly. Otherwise it's a bug.

Getting back to the facts, I know from my own professional experience and low-level detail about it that absolutely all "WiFi Mesh" devices (EasyMesh or Whole Home Mesh proprietary) perform this functionality (which is an explicit capability in EasyMesh which stipulates that devices without dedicated radio for monitor mode coexist with that mode).

Also I have had success with OpenWRT in these configurations in the past.

Anyway, recalling to what's important here: there is no way to deny that the mere fact of turning on an interface in monitor mode (when it is supported) destroys the operation of the Wi-Fi and, if not contained, of the entire device, would be a problem.