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?

ewhac
  • 1,003
  • 2
  • 10
  • 24
  • 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. – saiarcot895 Jan 07 '16 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 07 '16 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. – Chris Davies Jul 14 '16 at 23:19

4 Answers4

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
ewhac
  • 1,003
  • 2
  • 10
  • 24
  • 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. – CMCDragonkai May 01 '17 at 07: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 '23 at 00: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 '23 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 '23 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 '23 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
Philip
  • 141
  • Thank you; I will try that. BTW, what is "LAR"? Is it that radar avoidance thing for the 5GHz band? – ewhac Mar 15 '17 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 '17 at 17:31
  • 1
    @ewhac https://unix.stackexchange.com/a/385590/3285 – Evan Carroll Aug 11 '17 at 21:27
  • Good answer. Thank you very much. – Mohamed Bana Apr 14 '20 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 02 '23 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.

Nikita Kipriyanov
  • 1,549
-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"
muru
  • 72,889
Joel Cruz
  • 5
  • 2
    Please make a description of the code presented. Help users learn how to fish, not only give them a fish. –  Jan 29 '18 at 02: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 – JackGrinningCat Oct 19 '18 at 14:35