There is a patch made by tildearrow that will fix the hostapd package so that you can use the 5GHz band with Intel's ax 200 and ax 210. For this patch to work you need to build a custom image of OpenWrt and add the patch in /package/network/services/hostapd/patches in your build directory. Here is the patch HostAPD patch
3 Likes
1 Like
Why are there no comments/reaction about this? Am I missing something?
What kind of comments or reactions are you expecting?
These patches don't have a snowball's chance in hell to be accepted upstream (nor in OpenWrt), as they are hacks, ignoring real issues and hard requirements of the IEEE 802.11 standards. Yes, you can use them to get things (kind of and in a limited and specific way, ignoring legal requirements on DFS) 'working', but they are far from production ready - and never will be, unless Intel would work on the firmware side of it to support the missing requirements (and it's clear that they don't want to do that, as they've been treating DFS like a hot potato from the beginning, rejecting any features that would need it), so the driver can do this properly.
2 Likes
not working with my AX210, no channel 149~161 on my AX210
[rant warning]
OTOH I'm not surprised of such patches appearing, giving how braindead the whole idea of LAR is, and how bad it works in many situations.
Recently, debug knob for disabling LAR was removed from the Kernel, which IMO falls under "we never break the userspace" category.
If the card guesses regulatory domain wrongly, just because it hears a misconfigured AP first, this can screw with your network badly. Just because someone misconfigured their AP, or forgot to change regulatory domain after moving from another country. Let's assume you have an AP set at channel 149, and someone has a regulatory domain set that doesn't allow this channel, and card guesses the domain based on it, then refusing to connect to your AP just because of this, let alone setting up an AP on this channel on an Intel card.
After this change, I decided to rip out all Intel cards from my machines, and replace them with ath9k or ath10k. Never looked back.
Was the knob part of sysfs or debugfs?
I agree on the crap that everybody is doing with the damn FW regulatory databases and learning from the neighbors, there is way higher change the regdomain is misconfigured than being right
I need to double-check that, will find discussion on LKML and link it here. Hell, I even wanted to send a revert for this patch, noting "we never break the userspace" rule and CC Linus.
For me, Intel's done for.
The thing is that if its in debugfs then there are no guarantees and they did not break anything
Probably
1 Like
Module parameters are tricky, personally I dont think they are part of API/ABI and not stable at all
Even if it were considered API/ ABI, that would probably only go as far as retaining the parameter as a NOOP (regulatory enforcement is probably considered a legal necessity and -similar to security bugs- not really up for discussion[0]) - aside from 3 years and two LTS kernel releases later, no one is going to look at this kind of potential 'regression' anymore anyways.
--
[0] as long as the hardware does the intended thing, which isn't necessarily what its users want it to.
hi you git now not work ? you can send me this patch