Bug 205695

Created attachment 286107 [details]
dmesg with iwlwifi debug=0x00014004 (IWL_DL_FW | IWL_DL_LAR | IWL_DL_HCMD)

Same on Slackware and Arch.


Kernels: 5.4.1 & 5.4.2 are both broken.

Kernel: 5.3.8 works just fine.

WiFi card is: Intel 9560

I'm seeing the same symptoms with Intel 8265. Works with 5.3, fails with 5.4.

Removing lar_disable=Y works it around.

There's a bug entry on Arch, https://bugs.archlinux.org/task/64703, where somebody bisected it and came up with the following patch: https://bugs.archlinux.org/task/64703?getfile=18121. It worked for me as well...

Why are you normally disabling LAR? This is an old parameter that was used only when LAR was still under development.  I'll actually remove it from the driver now, since the end-users are not supposed to disable it.

This bug may not be directly related to LAR, though, but related to something in the number of channels or something like, so I won't close this bug yet.

I believe I originally disabled it because when it was enabled, I could not use "iw reg set".  So LAR seemed like an anti-feature.  See, e.g., https://unix.stackexchange.com/questions/286258/intel-wireless-7265d-iw-shows-wrong-regulatory-information

I don't know if that was fixed in the meantime or if I fundamentally misunderstood the purpose of LAR for the beginning.  I would welcome any insight you may have.

This is a feature where the FW listens to the environment (mainly beacons and probe_responses from surrounding APs) and detects the location accordingly.  The FW has an algorithm to make this decision without relying on the userspace to provide the location information.

That's why you can't change the regulatory settings from the userspace anymore.  Disabling LAR doesn't help you and can potentially cause problems as the one you experienced.

I'll proceed in removing this option and then mark this bug as closed.

Thanks for reporting! :)

I have created the patch internally and will close this bug once I send it upstream.

Unconditionally relying on information from adjacent APs sounds like an anti-feature indeed. Will there be no other way to disable this behavior?

It's not unconditionally, there is some logic that makes the decision trustworthy.

I am having the same problem

Kernel: 5.3.x (x : 8,13) works perfectly fine

Kernel: 5.4.x (x : 2,3,4,6) is broken

WiFi card is: Intel 9560

(In reply to Luca Coelho from comment #4)
> Why are you normally disabling LAR? This is an old parameter that was used
> only when LAR was still under development.  I'll actually remove it from the
> driver now, since the end-users are not supposed to disable it.
> 
> This bug may not be directly related to LAR, though, but related to
> something in the number of channels or something like, so I won't close this
> bug yet.

please dont remove `lar_disable` functionality, LAR is a great feature in theory but when it fails to work properly if fails spectacularly. without disabling LAR, 5ghz ac channels get disabled except for 149@20mhz and only if i lock it to 20mhz on the router. even when im able to get the card to detect "country US: DFS-FCC" it will also show "country ID: DFS-UNSET" just below it on `iw reg get` output and it disables all the channels i should available to me here in the US. i do not live near any radar stations and every non-intel device i own does not have this problem. this same issue happens on the oem 3165ngw, 8265ngw, and 9260. 

on linux im able to remedy this with lar_disable=Y and get the full 1733mbit/s up/down 160mhz link speed but only with that module option. on windows there is no lar_disable and im left with using a second router as a network bridge running a lan cable from it. 

related links, steps i've taken over the last few months since the issue began.
https://forums.intel.com/s/question/0D50P00004VggYA/wireless-ac-9260-regulatory-lardrs-breaks-5ghz-functionality?language=en_US
another user, same problem.
https://forums.intel.com/s/question/0D70P000006drPk/wireless-ac-8265-ax-200-sets-the-incorrect-regulatory-domain

additional supporting logs.

##
with no option other than enabling debug (lar_disable=0)
`dmesg|grep -i iwl`
https://pastebin.com/uZdptEHb

`iwlist chan`
https://pastebin.com/8wQZZp1L

`iw reg get`
 https://pastebin.com/FuziP013

 lar detects US like it should and then goes on to detect "ID" indonesia which
 disables all 5ghz channels except 149-161 and only at 20mhz width.


##
with debug and lar_disable=1 

`dmesg|grep -i iwl`
https://pastebin.com/PMcHrxMP

`iwlist chan`
https://pastebin.com/W4HKKwYE

`iw reg get`
https://pastebin.com/8wQZZp1L

with lar_disable, everything works as it should. only US is detected and my channels 
dont get crippled.

Luca, I would like to ask whether the default behavior would be if the surrounding radio signal is not available (like, in a room where all Wi-Fi signals are isolated or a (very) secluded area where no AP signals are even available)?

Also IMO the driver/firmware should at least allow the user to override the regulatory settings when LAR doesn't detect proper regulatory regions.

As noted above, `lar_disable` is useful when LAR isn't working correctly and there are plenty of examples of LAR not working correctly out on Intel's community web forums.  Often the 'answer' on said forums is to submit a troubleticket to one's OEM, but often (at least historically), many OEMs don't even support Linux on their notebook computers.  IMO, keeping the `lar_disable` debugging / troubleshooting / override available is useful, and given how it is buried, doubt 'regular' users are going to stumble upon it and flip it on unintentionally.

Is the logic that implements how LAR works and makes the region determination on the adapter well documented and open-source?  If not, then it is concerning we are losing the ability to disable a blackbox.

To further expand on Comment 13, what happens if there are (intentionally or unintentionally) misconfigured APs beyond the control of the user that causes LAR to make an incorrect region determination?

Automatically detecting the Wi-Fi region is a nice idea but in far too many cases it simply doesn't work. And in precisely such cases, the user must be allowed to set this himself.

My case:
I live in Switzerland and my "Intel Corporation Dual Band Wireless-AC 8265" sets itself to "DE", which is strictly speaking illegal. And I no longer have the possibility to change this.

Please reverse this change!

Translated with www.DeepL.com/Translator (free version)

Same issue here, with an Intel 8260, my region is getting set to CN "self-managed" while I'm actually in the US. Whatever algorithm is being used by the firmware - it's making an incorrect decision and I can't override it.

The decision to take away disable_lar option was very wrong.
Please reinstate it or provide another mechanism to allow users to override dumb decisions made by dumb firmware.

This is another reason to stay away from intel hardware.

+1 From my side. Looks like without it it's impossible to start hostapd on 5Ghz, because all channels are either NO-IR or straight disables. iw reg set is showing fine until hostap try to start, then it shows up like following:
$ iw list
...
               Frequencies:
                        * 5180 MHz [36] (22.0 dBm) (no IR)
                        * 5200 MHz [40] (22.0 dBm) (no IR)
                        * 5220 MHz [44] (22.0 dBm) (no IR)
                        * 5240 MHz [48] (22.0 dBm) (no IR)
                        * 5260 MHz [52] (22.0 dBm) (no IR, radar detection)
                        * 5280 MHz [56] (22.0 dBm) (no IR, radar detection)
                        * 5300 MHz [60] (22.0 dBm) (no IR, radar detection)
                        * 5320 MHz [64] (22.0 dBm) (no IR, radar detection)
                        * 5340 MHz [68] (disabled)
                        * 5360 MHz [72] (disabled)
                        * 5380 MHz [76] (disabled)
                        * 5400 MHz [80] (disabled)
                        * 5420 MHz [84] (disabled)
                        * 5440 MHz [88] (disabled)
                        * 5460 MHz [92] (disabled)
                        * 5480 MHz [96] (disabled)
                        * 5500 MHz [100] (22.0 dBm) (no IR, radar detection)
                        * 5520 MHz [104] (22.0 dBm) (no IR, radar detection)
                        * 5540 MHz [108] (22.0 dBm) (no IR, radar detection)
                        * 5560 MHz [112] (22.0 dBm) (no IR, radar detection)
                        * 5580 MHz [116] (22.0 dBm) (no IR, radar detection)
                        * 5600 MHz [120] (22.0 dBm) (no IR, radar detection)
                        * 5620 MHz [124] (22.0 dBm) (no IR, radar detection)
                        * 5640 MHz [128] (22.0 dBm) (no IR, radar detection)
                        * 5660 MHz [132] (22.0 dBm) (no IR, radar detection)
                        * 5680 MHz [136] (22.0 dBm) (no IR, radar detection)
                        * 5700 MHz [140] (22.0 dBm) (no IR, radar detection)
                        * 5720 MHz [144] (22.0 dBm) (no IR, radar detection)
                        * 5745 MHz [149] (22.0 dBm) (no IR)
                        * 5765 MHz [153] (22.0 dBm) (no IR)
                        * 5785 MHz [157] (22.0 dBm) (no IR)
                        * 5805 MHz [161] (22.0 dBm) (no IR)
                        * 5825 MHz [165] (22.0 dBm) (no IR)
                        * 5845 MHz [169] (disabled)
                        * 5865 MHz [173] (disabled)
                        * 5885 MHz [177] (disabled)
                        * 5905 MHz [181] (disabled)

$ iw reg get
global
country DE: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
        (5725 - 5875 @ 80), (N/A, 13), (N/A)
        (5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0 (self-managed)
country 00: DFS-UNSET
        (2402 - 2437 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
        (2422 - 2462 @ 40), (6, 22), (N/A), AUTO-BW, NO-80MHZ, NO-160MHZ
        (2447 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-80MHZ, NO-160MHZ
        (5170 - 5190 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5190 - 5210 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5210 - 5230 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5230 - 5250 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5250 - 5270 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5270 - 5290 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5290 - 5310 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5310 - 5330 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5490 - 5510 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5510 - 5530 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5530 - 5550 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5550 - 5570 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5570 - 5590 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5590 - 5610 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5610 - 5630 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5630 - 5650 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5650 - 5670 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5670 - 5690 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5690 - 5710 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5710 - 5730 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5735 - 5755 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5755 - 5775 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5775 - 5795 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5795 - 5815 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5815 - 5835 @ 20), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-HT40PLUS, NO-80MHZ, NO-160MHZ, PASSIVE-SCAN

The fix breaks a lot more, just tested with ax210 and I have similar problems.

(In reply to Luca Coelho from comment #9)
> It's not unconditionally, there is some logic that makes the decision
> trustworthy.

"some logic"? So, I'm interested in how does it work when:

-There are no APs around
-There are multiple APs that broadcast different country codes

Does it receive the GPS signal? GSM? Does it receive FM radio? Are there some secret Intel devices that beacon true country-code throughout the world? Does it listen for the language in which humans around are communicating?

Sorry, bad try. It does not solve any real problem, It does not work in many real-world scenarios, it adds unnecessary restrictions and decreases the true value of your wireless. Please, just allow us to disable it.

More importantly this seems to be a change that goes "windows way", I mean the wifi card is mine and I want to be able to set it up the way I see fit. Most of the time it is because the Intel self management chooses the wrong regulatory domain, but even if I want to ignore my local regulations I want to be able to do that on my own responsibility. I agree this should not be easy, but recompiling a kernel is too much of a deterrent, especially if you can't get your wifi to work properly.
In my case it is a problem with the metalic case of my laptop which is not mitigated by my laptop manufacturer. I need to put my laptop next to a router to connect to it, while my phone (which is unmodified hence I assume is legal, can connect to the router from 50m+ in my environment...
This definitely does not seem to be the Linux way to deal with things, but closely reassembles proprietary software way.
Sorry for the rant... is there a fix?

Just leaving my 0,02. Please add the lar_disable parameter back. This is still an issue with the Archlinux kernel version 5.17.9.

This LAR as a feature is not helpful. I am located in a rural area with no wifi around making this mechanism completely moot, yet I cannot set the regulatory domain via my configuration. The comment earlier stating there is "logic that makes the decision trustworthy" seems completely inaccurate. We don't have details to support the comment either.

This bug really needs to be reopened. It should not be marked as CLOSED when the issue still exists. Where is the code fix?

Simply add the lar_disable parameter back and many people will go back to being happy in the countryside.

I see that there is absolutely no will on Intel's side to do anything about it. Guys are living in their bubbles thinking that anywhere in the world there is an AP within reach... LAR is a  "solution" that has been created as a way to get around regulations and actually does not work correctly in multiple scenarios. Solutions like these tend to stay stinking around for a long time.

But don't be sad, I have already started with some research about alternatives.
Realtek RTL8852AE-based WNFT-238AX by Sparklan works like a charm with the latest open-source drivers - letting you create even 80MHz wide AP with AX (experimental hostapd functionalities) and taking userspace regulations into consideration ;)

> Luca Coelho 2019-12-16 20:15:28 UTC: (Comment #6)
> 
> This is a feature where the FW listens to the environment
>  (mainly beacons and probe_responses from surrounding APs)
>  and detects the location accordingly.

The ENVIRONMENT can be contaminated by non-complying APs and thus BE UNRELIABLE.

> The FW has an algorithm to make this decision without
> relying on the userspace to provide the location information.
> That's why you can't change the regulatory settings from
> the userspace anymore.

An algorithm that makes a decision from an UNRELIABLE ENVIRONMENT, CAN BE WRONG.
If a kernel space decision CAN BE WRONG, it should also be able to rely on the
userspace the provide the CORRECT DECISION.

> Disabling LAR doesn't help you and can potentially cause
> problems as the one you experienced.

Disabling a FEATURE shouldn't cause a CRASH (unless it's a vehicle feature, which may _literally_ cause crashes), if there's a CRASH when the user disables a feature, FIX THE PLACE THAT CAUSES THE CRASH instead of REMOVING THE FEATURE SWITCH.

> I'll proceed in removing this option and then mark this
> bug as closed.

Dropping the FEATURE that enables a user to FIX A WRONG DECISION isn't helping!

> Thanks for reporting! :)

No thanks for the CODE_FIX that doesn't actually FIX THE CODE and creates more problems...  :) I guess.

LAR _assumes_ the signals in the surrounding environment are regulation-compliant and trustworthy, which is definitely NOT the case in the REAL WORLD.  Surrounding neighbors may use one or many wireless stations that are not compliant and it's NOT the user's responsibility to fix that even if that's feasibly possible.

Another problem is that if the logic of the black box erroneously set a regulatory that is ILLEGAL in the location, making the feature WITHOUT A DISABLE SWITCH drags the users into LEGAL RISKS.

Someone should really revert the following patch:

iwlwifi: remove lar_disable module parameter · torvalds/linux@f06021a
https://github.com/torvalds/linux/commit/f06021a18fcf8d8a1e79c5e0a8ec4eb2b038e153

or sue Intel for not adding a big red warning text that mentions this anti-feature on their products and the third-party OEM products that include their products.

In the meantime, we should have a kernel fork that drops this anti-feature and provide an alternative workaround for the users that haven't had the chance to switch to other competitive brands that can properly do the regulatory compliance without this mess.

Feel free to use the "fuck-intel-lar" name for the kernel fork ;).

I cannot use my 3165 chip AP mode using 5Gh because of this s**t.

If you are disallowing us from disabling LAR at least make sure it works correctly. Ironically i do have another AP in 5Ghz right next to this host with 3165.

So much for "This is a feature where the FW listens to the environment (mainly beacons and probe_responses from surrounding APs) and detects the location accordingly. "

Thanks Luca Coelho and Intel.

This is not my fault, nor Intel's, but regulatory's.

Additionally, these devices do not officially support AP mode in 5 GHz, so using it as such is not something that the driver should officially support.

In any case, I don't work with WiFi anymore, so call out on me will have no effect from now on.

These regulations certainly do not allow you (yourself, Intel or whoever) to criminalize users. Not even if they use functions that were not officially sold with the product but are still included in the driver. In addition, this faulty detection of the locally allowed frequencies too often does not work outside of any AP mode.

If it is not possible (and this is obviously the case here) to implement this automated detection in such a way that users are not forced to break the law, then it is simply illegal (regardless of any regulations).

Translated with www.DeepL.com/Translator (free version)