Created attachment 286105 [details]
Distro: Arch Linux
Since 5.4, if lar_disable=1 is set, iwlwifi reports a crash when trying to bring the interface up.
# ip l s wlp58s0 up
RTNETLINK answers: Input/output error
Dmesg is attached. Unfortunately, I failed to collect a firmware dump, even with the debug firmware.
% ethtool -i wlp58s0
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.
another user, same problem.
additional supporting logs.
with no option other than enabling debug (lar_disable=0)
`dmesg|grep -i iwl`
`iw reg get`
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`
`iw reg get`
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.
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)