5 ms·

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

by csdvrx 4y ago

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
    - dcow 4y ago
- phoronixrly 4y ago
  Can I just point out how insane this method of determining the regulatory rules is... Considering the average user would never bother to set their correct regdomain when they buy a crap Chinese wifi router, you are pretty much guaranteed to always be using the wrong (mostly CN) regdomain, because that's what your neighbours are using...
  - csdvrx 4y ago
    > you are pretty much guaranteed to always be using the wrong (mostly CN) regdomain Exactly. The software should make it easier for the average user to do the right thing. Most people would select "US" in a dropdown menu if offered the chance. The windows driver could also pass the information to the firmware using geolocalization or the windows locale settings if what the firmware setting suggested by default seems awfully wrong (ex: CN regdomain while Windows locale = US, geo IP = US, GPS=US etc)
- Avamander 4y ago
  Those problems are valid, but LAR is currently often unable to detect the correct location. Even though it seems to fail to a very restrictive default, it might not, potentially causing even worse problems than a (rare) manual override would. It also doesn't seem to be that much of an issue for other vendors to allow the user to configure their regulatory locale, it definitely raises the question how necessary this current approach is. In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated.
  - csdvrx 4y ago
    > In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated. Fully agreed with all this. If there's no existing patch for the 6.2 kernel I'll make my own later today because for whatever reason my Intel wifi card thinks it's not in the US (!!!) and I want it to obey the FCC limits. # iw reg get global country 00: DFS-UNSET (2402 - 2472 @ 40), (6, 20), (N/A) (2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN (5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN (5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN (5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN (57240 - 63720 @ 2160), (N/A, 0), (N/A) I've tried but failed to add regulatory.db to my bzImage: # dmesg | grep regula cfg80211: Loading compiled-in X.509 certificates for regulatory database platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 cfg80211: failed to load regulatory.db In my .config: CONFIG_EXTRA_FIRMWARE="iwlwifi-so-a0-gf-a0-72.ucode iwlwifi-so-a0-gf-a0.pnvm regulatory.db (...) regulatory.db exists in the expected path and the md5sum 968432874991bf18d99a4f508fb1515d seems correct.
    - 4y ago
- csdvrx 4y ago
  > 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. Not my clown, not my circus. If the wifi firmware thinks the regulatory area is ID (Indonesia) it's wrong anyway > WiFi chips should probably have some fuse in them that decides what regulatory region they were made for Yes let's block most of resale of used chip and make the problem worse by having the remaining market just be for chips for a "nice" regulatory region that has the channels you want even if it shouldn't! /s No, the answer is to fix the sar logic so that if it gives obviously wrong results, the correct setting can be passed to the firmware. It's up to the customer to obey the limits, and this feature wouldn't make it easy for customers to "ignore regulatory limits" but do the exact opposite: allow them to OBEY the regulatory limits while the setting clearly does the opposite for now (unless Indonesia is a subset of the US SAR settings, which I don't think it is) If my wifi think I'm not in the US, I will tell it yes, indeed we are, and it's on me if I lie to software. Most people will not lie. Why make it harder to do the right things?
- AlphaSite 4y ago
  I move and travel? My hardware will do super illegal things if I can’t change the regions.
  - Waterluvian 4y ago
    I just had an amusing daydream about routers adding GPS to handle this. And having to ask my grandma to go outside and hold her router up to the sun for a few minutes.
- aidenn0 4y ago
  > 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. So you need to travel with like a dozen WiFi cards? Setting the region in software is a feature to all travelers...
  - supertrope 4y ago
    Governments and businesses make international travel more inconvenient through the trade offs they make because most people don’t travel. Selling a solution to these cross border problems is another revenue stream. Some appliances aren’t 100-240V. Geolocation enforces region based pricing. Cell phone plan costs vary by several orders of magnitude.
    - rvba 4y ago
      Can this "open" option to switch firmware even cause any real damage? Millions of people travel each year with those chips and nothing happens?
- zelon88 4y ago
  The problem with using a fuse instead of software is that with software you can modify the regulatory value later. Like when a device leaves one regulatory domain and enters a different one.
- hakfoo 4y ago
  Wouldn't 10 cents worth of EPROM be a suitable choice? First boot, it supports the least-common-denominator channels, and you run an application with a big clicky flag icon to specify the regulatory environment. The OEM could even run this before shipment since he knows where the device is being shipped to. If you move, or travel, run the program and click a different flag. It's not unreasonable to expect the customer to know which country he currently resides in.

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

by csdvrx 4y ago

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

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
  - dcow 4y ago
phoronixrly 4y ago
Can I just point out how insane this method of determining the regulatory rules is... Considering the average user would never bother to set their correct regdomain when they buy a crap Chinese wifi router, you are pretty much guaranteed to always be using the wrong (mostly CN) regdomain, because that's what your neighbours are using...
- csdvrx 4y ago
  > you are pretty much guaranteed to always be using the wrong (mostly CN) regdomain Exactly. The software should make it easier for the average user to do the right thing. Most people would select "US" in a dropdown menu if offered the chance. The windows driver could also pass the information to the firmware using geolocalization or the windows locale settings if what the firmware setting suggested by default seems awfully wrong (ex: CN regdomain while Windows locale = US, geo IP = US, GPS=US etc)
Avamander 4y ago
Those problems are valid, but LAR is currently often unable to detect the correct location. Even though it seems to fail to a very restrictive default, it might not, potentially causing even worse problems than a (rare) manual override would. It also doesn't seem to be that much of an issue for other vendors to allow the user to configure their regulatory locale, it definitely raises the question how necessary this current approach is. In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated.
- csdvrx 4y ago
  > In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated. Fully agreed with all this. If there's no existing patch for the 6.2 kernel I'll make my own later today because for whatever reason my Intel wifi card thinks it's not in the US (!!!) and I want it to obey the FCC limits. # iw reg get global country 00: DFS-UNSET (2402 - 2472 @ 40), (6, 20), (N/A) (2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN (5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN (5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN (5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN (57240 - 63720 @ 2160), (N/A, 0), (N/A) I've tried but failed to add regulatory.db to my bzImage: # dmesg | grep regula cfg80211: Loading compiled-in X.509 certificates for regulatory database platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 cfg80211: failed to load regulatory.db In my .config: CONFIG_EXTRA_FIRMWARE="iwlwifi-so-a0-gf-a0-72.ucode iwlwifi-so-a0-gf-a0.pnvm regulatory.db (...) regulatory.db exists in the expected path and the md5sum 968432874991bf18d99a4f508fb1515d seems correct.
  - 4y ago
csdvrx 4y ago
> 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. Not my clown, not my circus. If the wifi firmware thinks the regulatory area is ID (Indonesia) it's wrong anyway > WiFi chips should probably have some fuse in them that decides what regulatory region they were made for Yes let's block most of resale of used chip and make the problem worse by having the remaining market just be for chips for a "nice" regulatory region that has the channels you want even if it shouldn't! /s No, the answer is to fix the sar logic so that if it gives obviously wrong results, the correct setting can be passed to the firmware. It's up to the customer to obey the limits, and this feature wouldn't make it easy for customers to "ignore regulatory limits" but do the exact opposite: allow them to OBEY the regulatory limits while the setting clearly does the opposite for now (unless Indonesia is a subset of the US SAR settings, which I don't think it is) If my wifi think I'm not in the US, I will tell it yes, indeed we are, and it's on me if I lie to software. Most people will not lie. Why make it harder to do the right things?
AlphaSite 4y ago
I move and travel? My hardware will do super illegal things if I can’t change the regions.
- Waterluvian 4y ago
  I just had an amusing daydream about routers adding GPS to handle this. And having to ask my grandma to go outside and hold her router up to the sun for a few minutes.
aidenn0 4y ago
> 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. So you need to travel with like a dozen WiFi cards? Setting the region in software is a feature to all travelers...
- supertrope 4y ago
  Governments and businesses make international travel more inconvenient through the trade offs they make because most people don’t travel. Selling a solution to these cross border problems is another revenue stream. Some appliances aren’t 100-240V. Geolocation enforces region based pricing. Cell phone plan costs vary by several orders of magnitude.
  - rvba 4y ago
    Can this "open" option to switch firmware even cause any real damage? Millions of people travel each year with those chips and nothing happens?
zelon88 4y ago
The problem with using a fuse instead of software is that with software you can modify the regulatory value later. Like when a device leaves one regulatory domain and enters a different one.
hakfoo 4y ago
Wouldn't 10 cents worth of EPROM be a suitable choice? First boot, it supports the least-common-denominator channels, and you run an application with a big clicky flag icon to specify the regulatory environment. The OEM could even run this before shipment since he knows where the device is being shipped to. If you move, or travel, run the program and click a different flag. It's not unreasonable to expect the customer to know which country he currently resides in.