Posts by reox

    Hi!
    I recently upgraded my APU1 based Router/AccessPoint from Debian Buster to Bullseye - just to find out that my 5GHz hostapd Access Point, using a Compex WLE200NX, does not work anymore.

    The reason for that is a change in the ath module, which overwrites the Region ID if the EEPROM has a value of 0x00 in it. I have to admit, I do not understand all the details of this change, but according to several explanations, the reason seems to be that the Qualcomm Standard says so and the manufacturers have used the value of 0x00 wrong.
    It seems, that the assumption of many manufacturers (including Compex and mikrotik) was, that 0x00 means "do whatever you want" - which seems not to be the case. There is this ML entry which explains some details: https://web.archive.org/web/20…el.wireless.general/38410

    it was discussed to revert the change, but it appears that they want to stick with the standard and do not change it - i.e. the hardware is broken because the manufacturer did not comply with the standard.

    See also https://lists.infradead.org/pi…k/2021-August/012795.html and other threads on that ML.


    So, this change in the kernel makes all (?) the Compex cards unusable as 5GHz APs and some distributions like OpenWRT ship now patches to overcome this issue.

    That means, in my case, I can either switch to a distribution which includes these patches or compile my own kernel or dkms.

    But I don't like this. I do not want to compile the kernel all the time and maintain patches. And I don't want to switch the distribution...


    So the question is now: Is there another way for Compex users to use the mainline kernel? And further: do newer Compex cards also have this issue (WLE600VX and WLE900VX seems to be affected as well)? Thus would it be sufficient to just buy a new card? According to the thread I linked above, one fix could also be that the manufacturer provides his own regulatory.bin. Is this the case?

    According to the many ML threads I have found, many of the users affected by this patch are pcengines users, thus I post this issue here as well, hoping that someone has found a better solution than rolling your own kernel.