22

In the process of trying to diagnose WiFi dropouts, I discovered that the regulatory domain on my WiFi interface is set to "world" (00), and changing it to my region (US) should help fix the issue. However, every attempt I've made to do so has been ignored.

Running iw reg set US has no evident effect:

$ iw reg get
country 00: DFS-UNSET
    (2402 - 2472 @ 40), (6, 20), (N/A)
    (2457 - 2482 @ 40), (6, 20), (N/A), PASSIVE-SCAN
    (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
    (5170 - 5250 @ 160), (6, 20), (N/A), PASSIVE-SCAN
    (5250 - 5330 @ 160), (6, 20), (0 ms), DFS, 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)
$ sudo iw reg set US
$ iw reg get
country 00: DFS-UNSET
    (2402 - 2472 @ 40), (6, 20), (N/A)
    (2457 - 2482 @ 40), (6, 20), (N/A), PASSIVE-SCAN
    (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
    (5170 - 5250 @ 160), (6, 20), (N/A), PASSIVE-SCAN
    (5250 - 5330 @ 160), (6, 20), (0 ms), DFS, 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)

After extensive Googling on the subject, it seems that what's supposed to happen is iw reg set causes the kernel to emit a udev event, which causes crda to get executed and cough up the relevant regulatory info. However, near as I can tell with udevadm, this event is never emitted. This event's absence is corroborated by the following kluge not working:

$ sudo iw reg set US; sudo COUNTRY=US crda
Failed to set regulatory domain: -7

The error message is from crda. The kernel will accept WiFi regulatory changes only if it has emitted a udev event/request for them and is expecting a response. Since crda fails, the kernel clearly wasn't expecting it, suggesting no udev event was emitted.

The WiFi interface is an Intel 7265D; whose kernel driver is iwlmvm. I have crda and wireless-regdb installed, and /etc/default/crda contains REGDOMAIN=US. Removing and reloading the iwlmvm driver has no effect.

Any suggestions of what more to check?

3
  • 1
    Have you checked the kernel log to see if any changes were made? I'm getting the same output as you are on stdout, but my logs say that the regulatory domain was indeed updated. Jan 7, 2016 at 18:58
  • I can find nothing in dmesg output or any of the logs to suggest that any attempt was made to change the regulatory domain. The only message to that effect appears when the driver is first loaded, reporting: "DFS master region: unset"
    – ewhac
    Jan 7, 2016 at 19:29
  • 1
    Your solution sounds good. Please move it to an answer rather than an edit in the question. You then get to accept your own answer, too. Jul 14, 2016 at 23:19

4 Answers 4

12

I tried revisiting this issue yesterday, and still have the problem even with kernel 4.6.3. Manually installing the latest firmware image also didn't help. However, trying iw reg set US on a second laptop running the same kernel worked fine.

The problem machine is a Thinkpad X1 Carbon (Gen.3), which has an Intel 7265D WiFi card; the working machine is a Thinkpad T440p, which has an Intel 7260. I therefore conclude that there's a bug in the 7265D driver or firmware.

Workaround

I also discovered a workaround for the 7265D. Be aware this is a workaround, and may cause conflicts if/when an actual fix is released:

  • Remove all WiFi kernel drivers and dependent modules:
    sudo modprobe -r iwlmvm
  • Install the cfg80211 kernel module, using a kernel parameter to force the regulatory domain (in this case, 'US'):
    sudo modprobe cfg80211 ieee80211_regdom=US
  • Re-install the WiFi kernel drivers:
    sudo modprobe iwlmvm

You should now see the WiFi interface configured for the US (or whatever) regulatory domain:

$ iw reg get
country US: DFS-FCC
    (2402 - 2472 @ 40), (N/A, 30), (N/A)
    (5170 - 5250 @ 80), (N/A, 17), (N/A)
    (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS
    (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
    (5735 - 5835 @ 80), (N/A, 30), (N/A)
    (57240 - 63720 @ 2160), (N/A, 40), (N/A)

Update 2016.11.17: Fixed in Kernel 4.8 Series

I checked this issue again today for the first time after updating a couple weeks ago to a 4.8.x kernel, and discovered that the WiFi interface is now seems to be properly accepting the regulatory domain. This happened in or prior to kernel rev 4.8.5.

$ 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)

phy#0 (self-managed)
country US: DFS-UNSET
    (2402 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-80MHZ, NO-160MHZ
    (5170 - 5250 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5250 - 5330 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5490 - 5730 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5735 - 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
5
  • This didn't work for my Intel Wireless 7265D, there are some threads on the internet mentioning that the 00-World setting is hardcoded into the firmware or hardware locked. May 1, 2017 at 7:55
  • It might accept it but it is still broken. It now disables DFS while with your previous fix DFS was still possible
    – Mehdi
    Mar 15, 2023 at 0:35
  • If you are in the US, try sudo iw reg set US to set the regulatory domain. The global section should then report DFS-FCC. (The self-managed section will still report unset.)
    – ewhac
    Apr 18, 2023 at 19:16
  • 1
    Alternatively, install the package crda, then edit /etc/default/crda and set REGDOMAIN to your two-character regulatory domain.
    – ewhac
    Apr 18, 2023 at 19:33
  • That modprobe command isn't permanent but you can make the option permanent by editing /etc/modprobe.d/cfg80211.conf and adding the line options cfg80211 ieee80211_regdom=US or you can simply run echo 'options cfg80211 ieee80211_regdom=US' | sudo tee -a /etc/modprobe.d/cfg80211.conf And on newer kernels like 5.14+ also make sure that the following is set to options cfg80211 internal_regdb=y and options cfg80211 crda_support=y And I believe you need the wireless-regdb package installed.
    – mchid
    Jun 23, 2023 at 12:18
12

After some code research I found out what the problem is:

The Intel WiFi device appears as a "self-manged" device, so the iw reg set won't be applied to it.

All you need to do is setting the iwlwifi parameter lar_disable=1:

  1. Either manually: modprobe -r iwlwifi & modprobe iwlwifi lar_disable=1
  2. Automatically: echo "options iwlwifi lar_disable=1" >/etc/modprobe.d/iwlwifi.conf
5
  • Thank you; I will try that. BTW, what is "LAR"? Is it that radar avoidance thing for the 5GHz band?
    – ewhac
    Mar 15, 2017 at 19:52
  • 2
    The file /etc/modprobe.d/iwlwifi.conf may exist so it is better to append. Either use >> instead of > or echo "options iwlwifi lar_disable=1" | sudo tee -a /etc/modprobe.d/iwlwifi.conf (gets root privileges as needed).
    – Lucas
    Apr 11, 2017 at 17:31
  • 1
    @ewhac unix.stackexchange.com/a/385590/3285 Aug 11, 2017 at 21:27
  • Good answer. Thank you very much. Apr 14, 2020 at 10:41
  • Ubuntu 20.04 with the Linux 5.15 kernel no longer seems to have the lar_disable parameter. As can be seen with ls /sys/module/iwlwifi/parameters
    – Akh
    Nov 2, 2023 at 17:00
0

In my case of BCM43228 (as reported by the b43 driver and lspci) nothing helped to see extended channels range permitted by the regdb while I was using the in-kernel b43 driver. Only the intersection of 00 and my local database (AM currently) was effectively awailable.

The switch to the proprietary broadcom-sta driver fixed the issue immediately and now I see all wireless networks I need. This driver calls the card BCM4359 in the dmesg, by the way.

-3
 #!/bin/bash

echo "hello root"
git clone git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git

echo ""
cd wireless-regdb/
sleep 3

echo ""
gedit db.txt
sleep 1

echo ""
make

echo ""
sudo rm /lib/crda/regulatory.bin

echo ""
sudo cp regulatory.bin /lib/crda/regulatory.bin

echo ""
sudo cp $USER.key.pub.pem /lib/crda/pubkeys/

echo ""
sudo iw reg get

echo ""
ip link set wlan1 down
sleep 3

echo "Boosting Tx Power To 30 Fixed"
iw dev wlan1 set txpower fixed 30mbm
sleep 3

echo "starting wlan1"
ip link set wlan1 up
sleep 2

echo "Checking wlan1 TxPower"
iw dev
sleep 3

echo "Checking Regulatory Domain"
iw reg get
sleep 2

echo "Good Luck"
2
  • 2
    Please make a description of the code presented. Help users learn how to fish, not only give them a fish.
    – user232326
    Jan 29, 2018 at 2:49
  • I know it does not answer the question and Jan might be right. But it is a tip in the right direction of the awareness of the underlying files used. Besides that i don't have that folder /lib/crda/regulatory.bin Oct 19, 2018 at 14:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .