firmware-brcm80211: BCM43455: most channels disabled for country KR

[nomatter2k]

From my RPi4B, setting WiFi country to KR (I'm in KR) makes most channels disabled except only 4 5GHz ones:

$ iw phy phy0 channels Band 1:

• 2412 MHz [1] (disabled)
• 2417 MHz [2] (disabled)
• 2422 MHz [3] (disabled)
• 2427 MHz [4] (disabled)
• 2432 MHz [5] (disabled)
• 2437 MHz [6] (disabled)
• 2442 MHz [7] (disabled)
• 2447 MHz [8] (disabled)
• 2452 MHz [9] (disabled)
• 2457 MHz [10] (disabled)
• 2462 MHz [11] (disabled)
• 2467 MHz [12] (disabled)
• 2472 MHz [13] (disabled)
• 2484 MHz [14] (disabled) Band 2:
• 5170 MHz [34] (disabled)
• 5180 MHz [36] (disabled)
• 5190 MHz [38] (disabled)
• 5200 MHz [40] (disabled)
• 5210 MHz [42] (disabled)
• 5220 MHz [44] (disabled)
• 5230 MHz [46] (disabled)
• 5240 MHz [48] (disabled)
• 5260 MHz [52] (disabled)
• 5280 MHz [56] (disabled)
• 5300 MHz [60] (disabled)
• 5320 MHz [64] (disabled)
• 5500 MHz [100] (disabled)
• 5520 MHz [104] (disabled)
• 5540 MHz [108] (disabled)
• 5560 MHz [112] (disabled)
• 5580 MHz [116] (disabled)
• 5600 MHz [120] (disabled)
• 5620 MHz [124] (disabled)
• 5640 MHz [128] (disabled)
• 5660 MHz [132] (disabled)
• 5680 MHz [136] (disabled)
• 5700 MHz [140] (disabled)
• 5720 MHz [144] (disabled)
• 5745 MHz [149] Maximum TX power: 20.0 dBm Channel widths: 20MHz
• 5765 MHz [153] Maximum TX power: 20.0 dBm Channel widths: 20MHz
• 5785 MHz [157] Maximum TX power: 20.0 dBm Channel widths: 20MHz
• 5805 MHz [161] Maximum TX power: 20.0 dBm Channel widths: 20MHz
• 5825 MHz [165] (disabled)

So I have problems in connecting to APs. If I set it to GB:

$ iw phy phy0 channels Band 1:

• 2412 MHz [1] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40+
• 2417 MHz [2] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40+
• 2422 MHz [3] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40+
• 2427 MHz [4] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40+
• 2432 MHz [5] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40- HT40+
• 2437 MHz [6] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40- HT40+
• 2442 MHz [7] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40- HT40+
• 2447 MHz [8] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40- HT40+
• 2452 MHz [9] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40- HT40+
• 2457 MHz [10] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40-
• 2462 MHz [11] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40-
• 2467 MHz [12] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40-
• 2472 MHz [13] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40-
• 2484 MHz [14] (disabled) Band 2:
• 5170 MHz [34] (disabled)
• 5180 MHz [36] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40+
• 5190 MHz [38] (disabled)
• 5200 MHz [40] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40-
• 5210 MHz [42] (disabled)
• 5220 MHz [44] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40+
• 5230 MHz [46] (disabled)
• 5240 MHz [48] Maximum TX power: 20.0 dBm Channel widths: 20MHz HT40-
• 5260 MHz [52] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40+ DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5280 MHz [56] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40- DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5300 MHz [60] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40+ DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5320 MHz [64] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40- DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5500 MHz [100] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40+ DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5520 MHz [104] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40- DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5540 MHz [108] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40+ DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5560 MHz [112] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40- DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5580 MHz [116] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40+ DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5600 MHz [120] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40- DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5620 MHz [124] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40+ DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5640 MHz [128] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40- DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5660 MHz [132] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40+ DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5680 MHz [136] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz HT40- DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5700 MHz [140] Maximum TX power: 20.0 dBm No IR Radar detection Channel widths: 20MHz DFS state: usable (for 19 sec) DFS CAC time: 60000 ms
• 5720 MHz [144] (disabled)
• 5745 MHz [149] (disabled)
• 5765 MHz [153] (disabled)
• 5785 MHz [157] (disabled)
• 5805 MHz [161] (disabled)
• 5825 MHz [165] (disabled)

I can see lots of enabled channels.. Looks like inverted..? If you need information about updated Korean regulation, maybe, I can help.

[nomatter2k]

Nobody interested? Should I make the request somewhere else?

[pelwell]

There is an ongoing issue with Cypress related to this that is likely to result in a new clm_blob file.

[pelwell]

In the meantime, can you try this worldwide-safe blob: https://drive.google.com/file/d/1Qoc90FCTO17d69PbBqUhkJKgqDMmdOui/view?usp=sharing

Make a backup of your old clm_blob and install the new one using:

$ sudo cp /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob{,.orig}
$ sudo cp 43455_raspberry_3p_v1_190515.clm_blob /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob

[pelwell]

N.B. This clm_blob isn't suitable for use on a 3B+ due to the way the two devices are programmed at manufacturing.

[nomatter2k]

Thank you for status update, pelwell!

Made a quick test for the clm_blob you linked:

new_clm_blob_GB.txt new_clm_blob_KR.txt org_clm_blob_GB.txt

The new clm_blob makes almost every channels enabled except channel 144, which is enabled in my AP. (I need to check the regulation to see which is correct) But its performance is not that good. Typing in terminal through WiFi shows long latencies sometimes, and iperf result to a local server is also unstable.

[pelwell]

Can you try the iperf test with power save disabled?

$ sudo iwconfig wlan0 power off

[nomatter2k]

iperf results are now stable with power management disabled:

1. new clm_blob with country code GB

   $ iperf -fm -i 1 -c 192.168.1.50
   ------------------------------------------------------------
   Client connecting to 192.168.1.50, TCP port 5001
   TCP window size: 0.15 MByte (default)
   ------------------------------------------------------------
   [  3] local 192.168.1.5 port 60924 connected with 192.168.1.50 port 5001
   [ ID] Interval       Transfer     Bandwidth
   [  3]  0.0- 1.0 sec  11.8 MBytes  98.6 Mbits/sec
   [  3]  1.0- 2.0 sec  11.6 MBytes  97.5 Mbits/sec
   [  3]  2.0- 3.0 sec  11.8 MBytes  98.6 Mbits/sec
   [  3]  3.0- 4.0 sec  11.4 MBytes  95.4 Mbits/sec
   [  3]  4.0- 5.0 sec  11.8 MBytes  98.6 Mbits/sec
   [  3]  5.0- 6.0 sec  12.1 MBytes   102 Mbits/sec
   [  3]  6.0- 7.0 sec  12.4 MBytes   104 Mbits/sec
   [  3]  7.0- 8.0 sec  12.4 MBytes   104 Mbits/sec
   [  3]  8.0- 9.0 sec  12.4 MBytes   104 Mbits/sec
   [  3]  9.0-10.0 sec  11.8 MBytes  98.6 Mbits/sec
   [  3]  0.0-10.0 sec   119 MBytes  99.8 Mbits/sec

2. new clm_blob with country code KR

   $ iperf -fm -i 1 -c 192.168.1.50
   ------------------------------------------------------------
   Client connecting to 192.168.1.50, TCP port 5001
   TCP window size: 0.10 MByte (default)
   ------------------------------------------------------------
   [  3] local 192.168.1.5 port 60926 connected with 192.168.1.50 port 5001
   [ ID] Interval       Transfer     Bandwidth
   [  3]  0.0- 1.0 sec  11.9 MBytes  99.6 Mbits/sec
   [  3]  1.0- 2.0 sec  12.0 MBytes   101 Mbits/sec
   [  3]  2.0- 3.0 sec  11.5 MBytes  96.5 Mbits/sec
   [  3]  3.0- 4.0 sec  11.4 MBytes  95.4 Mbits/sec
   [  3]  4.0- 5.0 sec  11.5 MBytes  96.5 Mbits/sec
   [  3]  5.0- 6.0 sec  11.4 MBytes  95.4 Mbits/sec
   [  3]  6.0- 7.0 sec  11.5 MBytes  96.5 Mbits/sec
   [  3]  7.0- 8.0 sec  11.5 MBytes  96.5 Mbits/sec
   [  3]  8.0- 9.0 sec  11.6 MBytes  97.5 Mbits/sec
   [  3]  9.0-10.0 sec  11.5 MBytes  96.5 Mbits/sec
   [  3]  0.0-10.0 sec   116 MBytes  97.1 Mbits/sec

[pelwell]

Interesting. Are you running a stock Raspberry Pi OS kernel? We have a downstream patch to change the power saving timeout.

[nomatter2k]

Yes, it is a stock kernel:

$ uname -a
Linux raspi4b 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux
$ dmesg | head
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.118-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1311 SMP Mon Apr 27 14:26:42 BST 2020
[    0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 256 MiB at 0x000000001ec00000
[    0.000000] On node 0 totalpages: 999424
[    0.000000]   DMA zone: 1728 pages used for memmap

[nomatter2k]

@pelwell, if you want me to test with the patch you mentioned, send me a link to it.

[pelwell]

The patch in question has been in rpi-4.19.y since February, so your kernel should have it, which is really strange since the pattern of throughput I saw from your iperf tests reminded me of what it looks like with a very short timeout.

I suggest you add iwconfig wlan0 power off to /etc/rc.local - just before the exit 0 is fine. You can confirm that it works because after booting you'll see the following in the kernel log:

[    9.532391] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled

[nomatter2k]

Is power saving also affected by regulation?

[nomatter2k]

@pelwell, can you estimate the release of fixed firmware?

[pelwell]

Not yet - there are multiple ongoing investigations, and I still don't understand why you are affected by power-save problems.

[nomatter2k]

Mmm.. Two months without any progress?

[nomatter2k]

@pelwell It looks like that brcmfmac43455-sdio.clm_blob has multiple entries for country code KR, with different revisions (0~9). From the Cypress WiFi CLM Regulatory Manual, this is "Master CLM" type of clm_blob. To use this type of clm_blob properly, we need an interface to specify country code with revision. Raspberry Pi OS doesn't have such an interface, and the firmware selects the first entry with revision 0, which disables most of available channels. Cypress support told me the expected revision for KR country code to be used is 4. I found a "Per Product CLM" type of clm_blob from the recent Cypress Linux WiFi Driver Release, cyfmac43455-sdio.clm_blob which has single KR entry. With this file replacing existing brcmfmac43455-sdio.clm_blob, my RasPi4 booted okay, and got many available channels. Still I can see a few disabled channels in 5GHz, and some performance drop with power management enabled. However, the WiFi works with country code KR now. How do you think about upgrading firmware and clm_blobs to latest?

[pelwell]

That's an interesting explanation of the reason why KR is problematic. The route we expected to take was the single, worldwide safe country code that adapts to the local conditions, but that has caused other issues. This "Per Product CLM" you refer to is unlikely to be tuned to Raspberry Pi, so probably won't be adopted as the new standard.