4 ms·
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
by 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.
- kennethrc 4y agoMy regulatory.db (and regulatory.db.p7s) lives in /lib/firmware; have you tried copying it there? And I make "iwlwifi" a loadable module, so the userspace firmware loader can pick up the various firmware blobs once the rootfs is loaded (not a big fan of initrds).
- csdvrx 4y agoI'm trying to compile that in the kernel for some reasons related to startup optimization. The kernel sees them, and compiles them, and it WORKS with other things requiring a firmware like i915 with the HuC and the GuC, but not for regulatory.db