mvebu: Linksys WRT3200ACM and WRT32X: Remove SDIO wifi driver

[hauke]

The Linksys WRT3200ACM and WRT32X have an additional 1x1 88W8887 wifi
device connected over SDIO in addition to the main 4x4 88W8964 wifi.
The 88W8887 wifi chip is provisioned for the US regulatory domain also
on devices sold in the EU. The 88W8964 wifi chip is provisioned for FR
on devices sold in the EU. When Linux sees these two different Reg
domains it tried to merge them and only allows what is allowed in both
regions. This removes support for DFS channels.

As a workaround remove the driver for the SDIO wifi device.
If you need the extra wifi device just install the driver manually.
opkg install kmod-mwifiex-sdio

Fixes: #9956

[Shine-]

Please excuse my possibly unqualified comment, since I don't own a WRT32X anymore. So I can only speak from memory, but not test anything anymore.

From what I recall, I could never get DFS channels to work on my EU-provisioned WRT32X by just removing the kmod-mwifiex-sdio driver (and firmware). Also, my Amazon UK purchased WRT32X was provisioned for IT, not FR.

The 88W8887 chip (mwifiex driver) can be provisioned by software. It just defaults to "US", like e.g. ath9k/ath10k. But it's not locked to the EEPROM setting, like the 88W8964 is (mwlwifi driver).

It didn't help to set my OpenWrt regdomains for all WiFi chips to "IT" to match the EEPROM regdomain. The only way I could get DFS channels to work on my EU unit was to patch the mwlwifi driver to stop sticking to the EEPROM-defined region (as documented in the linked issue #9956). Then I could set my proper regdomain and all channels would work as expected. As I'm EU based, I never tested, though, whether this patch would allow me to change the regdom to a more lenient (or stricter) one than DFS-ETSI.

The mwlwifi driver is under community maintenance now and we can, since recently, finally see new updates and fixes again (like WPA3 support and more, see #14044). Therefore I'd suggest, instead of removing support for the perfectly working additional 5G chip in the WRT32X/WRT3200ACM, to fix this long-standing DFS resp. regdom mismatch issue at its origin, ie. in the mwlwifi driver?

[hauke]

I do not own such a device, it is pretty expensive and never well supported.

I do not want to remove the code which reads the country code from EEPROM, see #2397 Some regulatory bodies do not like OpenWrt because you can violate the regulatory requirements and I do not want to give them more attack surface. The vendor FW is done by "professions" and verified by "professions".

[Shine-]

Thanks for pointing me to that PR, that one was unknown to me.

That PR, and all the other patches (including mine) are in no way mergable. Since all the patches do is, prevent the mwlwifi driver from insisting to report its EEPROM regdom to Linux, regardless of what Linux requests. In addition, neither of the patches could, so far, do anything about the fact that the mwlwifi driver uses hardcoded, fixed TX power values. So this is all plain wrong and just a dirty workaround in order to be able to use DFS channels at all.

My point was, now that the mwlwifi driver appears to have attracted maintainers again, years after Marvell/NXP abandoned it, it might finally happen that the most annoying bugs get fixed, including the regdom mismatch that prevents DFS channels from being used. In a proper way, so OpenWrt won't have to resort to disabling a fully working chip (which, as mentioned above, hasn't helped anyway in my case), or violating regulatory rules.

[hnyman]

The "fully working chip" of radio2 is to my knowledge not connected to any real antenna like the main 2.4GHz and 5GHz normal radios.
The "third radio" was added later to the OpenWrt build, and has always caused problems.
I have removed it from my own WRT3200ACM builds since years ago.

+1 from me for the removal of the mwifiex driver for radio2.

[vitorcunha]

My WRT32X is now a backup, gathering dust. However, when it was used, if the mwifiex radio was configured properly it produced a noticeable stability improvement in 5GHz, especially when using 160MHz channels (i.e., things that relied heavily on DFS). That radio does not work properly out-of-the box -- in fact, in Europe, it is completely broken for that DFS purpose. But this radio fulfilled its intended purpose once you configure it properly (i.e., update the module loading with proper region parameter -- reg_alpha2=FR in my case).

Maybe things have changed with the latest driver developments. However, if we are going by the historical performance, removing mwifiex is a bit of a mistake – IMHO we should fix the bad defaults that make it problematic rather than remove it altogether.

-1

[PalebloodSky]

I'll also mention I've been removing it for years from my WRT32X via image builder too. The driver has been used as a work-around for connecting to buggy "ESP chip devices", but few if any people use it for that. It's already addressed on the doc page to add the driver if needed for that. I say remove.

[Kin9Loui3]

Yes please remove I've been doing it as well for several years myself. Have had several clients and myself continually removing with this command after each firmware update:

opkg remove kmod-mwifiex-sdio kmod-btmrvl mwifiex-sdio-firmware

It gets tedious after several hundred updates at this point over the years. I've tested many devices and tried to get the Radio2 working properly with no avail. It seems since Linksys never released the driver code to opensource like they said they would no real use unless properly sorted out. Unless using specific IoT devices that barely function with it not real functional. I'm all for removing it completely as this point just sits there not being used. I also used to work with the WRT PureFusion Action-Build Team before it went offline. I vote remove as well.

+1 Vote for removal I've owned and worked with every model except the WRT1200AC and currently have both the WRT32X and WRT3200ACM.

[almereyda]

To add a use case where the presence of radio2 on a WRT3200ACM has proven useful:

When the land line connection loses its route to [::]/0, the third radio interface can very well act as a WiFi client to a mobile hotspot without any stability issues encountered.

I'd be fine with having to install said packages manually after each upgrade, because it's a rare edge case and this way wouldn't invite regular users to use it.