4 ms·

>looks like lar_disable functionality was removed as of 5.5 kernel as a way to fix the firmware crash issue with iwlwifi, is that right? >[...] i've tried repl

>looks like lar_disable functionality was removed as of 5.5 kernel as a way to fix the firmware crash issue with iwlwifi, is that right? >[...] i've tried replacing the wifi adapter but this happens on intel wireless-ac 3165, 8265, and 9260 dual band 160Mhz (currently installed adapter). >[...] On Intel ax210ngw all 5ghz channels are disabled and cannot be used to transmit So it's iwlwifi specifically. >i should add that this happens on both windows and linux but at least on linux i had a way of disabling LAR so my regulatory domain gets detected properly and all the wifi channels/widths works as they should. >[...] on all 5.3 and earlier kernels, using lar_disable=1 all my channels work and i get a full 1733mbps link speed (5ghz ch.36 at 160mhz)as shown here So it's not a Linux-specific issue. Rather it seems to be buggy firmware, and a method that OP was relying on to work around that bug was disabled because it was causing other issues with said buggy firmware.

csdvrx 4y ago
Is there a patch for the kernel 6 line to add back the lar_disable functionality?
- stefan_ 4y ago
  This was the patch that removed it: https://github.com/torvalds/linux/commit/f06021a18fcf8d8a1e79c5e0a8ec4eb2b038e153 https://github.com/torvalds/linux/commit/f06021a18fcf8d8a1e7... But this commit message is burying the lede a bit. There are two problems here: 1) you can revert the change, but a large part of the regulatory logic lives in the firmware blob running on the chip and you can not change this. 2) the FCC doesn't look kindly upon functionality that ignores regulatory limits being available to end customers. It was already not legal for Intel to add this in the first place, and they certainly won't help you reinstate it. The second part might be why these devices have been in a "broken" regulatory state forever now where they stay away from everything that touches upon e.g. DFS; someone at Intel might have realized that letting users pick their regulatory region is already not something they should be offering. The reality is that these WiFi chips should probably have some fuse in them that decides what regulatory region they were made for and then run off that, but you can see the business people losing their mind over that: now you need to have a hundred different SKUs and worse you need to understand your distribution chain. So a software setting it is, and then you see why the FCC is upset.
  - mjevans 4y ago
    But what if someone moves or simply uses hardware in a different region that's sold? What if the laws change? The correct 'work around' is to build a kernel with a DEFAULT regulatory domain, abstract from any vendor's specific implementation, allow that domain to be updated at runtime (particularly for mobile devices), and follow the laws there in. I also advocate (in this post) for wifi_regulations=BREAKTHELAWANDDISABLE (allcaps required) to completely bypass filtering channels. This would be useful in some situations such as isolated testing environments, use in International Waters, and any other environment that's isolated enough.
    - jodrellblank 4y ago
      If you aren't breaking any laws transmitting like that in International Waters, why call it BREAKTHELAW and call out that use case? If you are breaking laws transmitting like that in International Waters, why would this setting be called out as specifically useful in International Waters? Neither seems to make sense. (And does this come from the Microsoft team who came up with setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF ?)
      - mjevans 4y ago
        It doesn't make sense to call the same option multiple things for such a small number of use cases; you really want the last thing, but someone might not know that in _many_ circumstances it could be against the law to use it, hence the prefix to document that. Edit: ALSO, in case it wasn't clear... E.G. wifi_regulations=USA or wifi_regulations=CDN or wifi_regulations=GBR or some other set of country codes / match in the table of known regulations. A longer string that manually specifies allowed frequencies in some way might also work.
    - stefan_ 4y ago
      Keep in mind that for stations only (e.g. mobile devices most of the time), the rules are relaxed: if the station sees an AP operating on some channel, it is allowed to assume that it can operate on that channel. And of course passively scanning a channel to check for the presence of an AP is not transmitting, so no regulatory problem there. But don't worry, for 6 GHz the FCC has come up with even more insane stuff: if you want to unlock more channels and power, your AP will have to (1) geolocate itself and (2) contact a central server to determine regulatory restrictions for that location. They are calling this Automatic Frequency Coordination (AFC). See page 13 of https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf: > We will require the AFC to use a centralized model where each standard-power access point remotely accesses an AFC to obtain a list of available frequency ranges in which it is permitted to operate and the maximum permissible power in each frequency range

csdvrx 4y ago

Is there a patch for the kernel 6 line to add back the lar_disable functionality?

stefan_ 4y ago
This was the patch that removed it: https://github.com/torvalds/linux/commit/f06021a18fcf8d8a1e79c5e0a8ec4eb2b038e153 https://github.com/torvalds/linux/commit/f06021a18fcf8d8a1e7... But this commit message is burying the lede a bit. There are two problems here: 1) you can revert the change, but a large part of the regulatory logic lives in the firmware blob running on the chip and you can not change this. 2) the FCC doesn't look kindly upon functionality that ignores regulatory limits being available to end customers. It was already not legal for Intel to add this in the first place, and they certainly won't help you reinstate it. The second part might be why these devices have been in a "broken" regulatory state forever now where they stay away from everything that touches upon e.g. DFS; someone at Intel might have realized that letting users pick their regulatory region is already not something they should be offering. The reality is that these WiFi chips should probably have some fuse in them that decides what regulatory region they were made for and then run off that, but you can see the business people losing their mind over that: now you need to have a hundred different SKUs and worse you need to understand your distribution chain. So a software setting it is, and then you see why the FCC is upset.
- mjevans 4y ago
  But what if someone moves or simply uses hardware in a different region that's sold? What if the laws change? The correct 'work around' is to build a kernel with a DEFAULT regulatory domain, abstract from any vendor's specific implementation, allow that domain to be updated at runtime (particularly for mobile devices), and follow the laws there in. I also advocate (in this post) for wifi_regulations=BREAKTHELAWANDDISABLE (allcaps required) to completely bypass filtering channels. This would be useful in some situations such as isolated testing environments, use in International Waters, and any other environment that's isolated enough.
  - jodrellblank 4y ago
    If you aren't breaking any laws transmitting like that in International Waters, why call it BREAKTHELAW and call out that use case? If you are breaking laws transmitting like that in International Waters, why would this setting be called out as specifically useful in International Waters? Neither seems to make sense. (And does this come from the Microsoft team who came up with setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF ?)
    - mjevans 4y ago
      It doesn't make sense to call the same option multiple things for such a small number of use cases; you really want the last thing, but someone might not know that in _many_ circumstances it could be against the law to use it, hence the prefix to document that. Edit: ALSO, in case it wasn't clear... E.G. wifi_regulations=USA or wifi_regulations=CDN or wifi_regulations=GBR or some other set of country codes / match in the table of known regulations. A longer string that manually specifies allowed frequencies in some way might also work.
  - stefan_ 4y ago
    Keep in mind that for stations only (e.g. mobile devices most of the time), the rules are relaxed: if the station sees an AP operating on some channel, it is allowed to assume that it can operate on that channel. And of course passively scanning a channel to check for the presence of an AP is not transmitting, so no regulatory problem there. But don't worry, for 6 GHz the FCC has come up with even more insane stuff: if you want to unlock more channels and power, your AP will have to (1) geolocate itself and (2) contact a central server to determine regulatory restrictions for that location. They are calling this Automatic Frequency Coordination (AFC). See page 13 of https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf: > We will require the AFC to use a centralized model where each standard-power access point remotely accesses an AFC to obtain a list of available frequency ranges in which it is permitted to operate and the maximum permissible power in each frequency range