Linux: RPi4: Wifi cannot connect to ac accesspoint (no VHT Capabilities)

Which country/regulatory domain are you in? Your wpa_supplicant.conf appears to have no "country=XX" line.

This is the output of "iw reg get":
global
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

The wifi accesspoint is configured for Germany, too.

My 4B has no difficulty connecting to an "ac" AP, and I suspect millions of other 4B and 3B+ users (they both use the same WiFi controller) are in the same position. I can think of four potential explanations for the difference:

1. Most ac APs don't require VHT capabilities, but yours does.
2. No ac APs require VHT capabilities - the failure to connect to your AP is caused by something else.
3. Most 43455-equipped Pis generate VHT capabilities, but your 4B with your configuration doesn't.
4. All 43455-equipped Pis generate VHT capabilities, but they aren't being captured and the problem is unrelated.

Please try connecting to your AP using the WiFi post-installation wizard on a fresh Raspbian download. If your AP is configured to require non-standard settings, please explain exactly which settings in your wpa_supplicant.conf are absolutely necessary.

According to my googling, VHT is another name for IEEE 802.11ac. Per https://www.electronicdesign.com/technologies/communications/article/21798297/understanding-ieee-80211ac-vht-wireless:

Also known as Very High Throughput (VHT), 802.11ac is positioned as the successor to 802.11n, known as High Throughput (HT).

So it appears, but that doesn't really move us forward.

@HardResetSolution How did you create that Wireshark capture? Does it require a monitor-mode device?

I had the chance to check interoparbility with 2 further wifi accesspoints. The 3 testet devices show the following behaviour:

FRITZ!Box 7590 -> PI sends no VHT Capabilities
Asus ac68u -> PI sends no VHT Capabilities
Netgear Nighthawk rax40 -> PI sends VHT Capabilities

asus_and_netgear.zip

For this test I used the WiFi post-installation wizard on a fresh Raspbian download.

wpa_supplicant.config is the following:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE

network={
ssid="MySSID"
psk="MySecurePsk"
key_mgmt=WPA-PSK
}

For the FRITZ!Box I could create the capture via the accesspoint itself. For Asus and Netgear I used a wifi sniffer (monitor mode).

@pelwell Which accesspoint did you use and how did you make sure the Raspberry PI is using "ac" and not "n"?

Which accesspoint did you use and how did you make sure the Raspberry PI is using "ac" and not "n"?

We have a Ubiquiti in-house WiFi network, and there's Netgear Nighthawk R7000 on my desk, and the 4B connects to both in the 5G band. Both are "ac" capable APs, but it is possible that these connections are "n" only - it's coming up with a 40MHz channel width.

I could check a few more accesspoints, but I'm not sure whether that will help us.
Does anybody have an idea how to check if the PI is connected via "n" or "ac". So far the only way I know is checking the GUI of the FRITZ!Box accesspoint.
As you mentioned my PIs also connect with 40MHz channel width - but that could be both: "n" or "ac".

Ubuntu has https://packages.ubuntu.com/eoan/iw which can show the bandwidth of a connection this way (on one of my rpi4B devices connected to a Ubiquiti nano-HD):

@rpi4:~$iw dev
phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr ******
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr ******
                ssid ******
                type managed
                channel 104 (5520 MHz), width: 80 MHz, center1: 5530 MHz
                txpower 31.00 dBm

(I must be connected through ac since I'm connected via an 80MHz channel.)

Hello,

I have the same issue.
I have a RPi4 and the router Fritz!Box 7590.

Usually my RPi-country code is set to DE:

I found out that if I set the RPi-region to US, a 5GHz ac connection is established:

The ac connection is then very unstable and disconnects even more often.

(RPi4 and SmartDevice are in the same room)

I see the same behaviour with my FRITZ!Box 7590 router.
Setting PIs region to "DE" leads to "n" connection.
Setting PIs region to "US" leads to "ac" connection.

In the attached capture you can see, that in packet 4 (region "DE") the VHT-Capabillities are missing but in packet 15 (region "US") they are included. This looks like a proof for misbehaviour of the PI for me.
capture.zip

I also had problems that my 4er Pi's had not connected to the AC grid. The problem is probably due to the reception performance of the Pi's. Using DD-WRT router software, I can set the transmission power separately, if I reduce the transmission power in the N 2.4 GHz network by -2 dB then the Pi's choose the AC network instead of the N 2.4 GHz network. So just think that the Pi's choose the stronger network and therefore always choose the stronger N 2.4 GHz network.

Perhaps it should be improved in the firmware that the AC network is given priority even if it is minimally weaker than the N network

I did a check, which country-codes result in an ac connection with FRITZ!Box 7590.

connection with ac:
AD, AU, NG, TZ, UG, US

connection with only n:
AR, AT, BE, BA, CH, CY, CZ, DK, DE, EE, ES, FI, FR, GR, GB, HU, IE, IL, IT, HR, LU, LV, ME, MK, NA, NZ, NL, NO, PL, PT, SE, SI, SK, TH, ZA

You can download a trial clm_blob file that may improve the connection options - it's available from 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

Reboot to use the new clm_blob.

N.B. This clm_blob is not suitable for use on a 3B+, so don't try this on a card that might be used on one.

I just tested the file, and no better.

The PI4 only connects in 2.4ghz g (signal -32 db ; tx: 48 mbit/s ; rx: 24 mbit/s)

Thie PI4 does not want to connect in 5ghz - 80mhz (802.11a, 802.11n, 802.11ac).

Pi4 is installed next to the router (freebox france)

should an option be activated?

country=fr
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="*****"
psk="******"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}

iw dev
phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr ***
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr ***
                ssid ***
                type managed
                channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
                txpower 31.00 dBm

What does iw phy0 channels report?

[updated with country code : fr]

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+ VHT80
        * 5190 MHz [38]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5200 MHz [40]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5210 MHz [42]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5220 MHz [44]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5230 MHz [46]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5240 MHz [48]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5260 MHz [52]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5280 MHz [56]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5300 MHz [60]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5320 MHz [64]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5500 MHz [100]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5520 MHz [104]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5540 MHz [108]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5560 MHz [112]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5580 MHz [116]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5600 MHz [120]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5620 MHz [124]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5640 MHz [128]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5660 MHz [132]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5680 MHz [136]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5700 MHz [140]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- VHT80
          DFS state: usable (for 144 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)

And how about iwconfig wlan0 and iw reg get?

$ iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"**"
          Mode:Managed  Frequency:2.412 GHz  Access Point: ***
          Bit Rate=54 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=67/70  Signal level=-43 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ iw reg get

country FR: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
        (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

Thanks. I'm looking at this area at the moment, so I'll try with your configuration as well.

thanks. I updated the comment for iw phy0 channels.
I was not on the fr code when I realized the first answer

I can't see an obvious reason why it wouldn't connect. Does the AP appear in scan results in the 5G band?

You could try adding brcmfmac.debug=0x100000 to cmdline.txt (keep it a single line) and try to connect. If your AP allows the two bands to be given different names, or for the 2.4G band to be switched off, try that as well.

No, the Ap appear only for 2g Band

$ iw wlan0 scan | grep -A5 'freq: 5'

return empty

the ap configuration :
primary wifi channel: 120
secondary wifi channel: 116

On 'iw reg get' command, what are the parameters?
DFS, AUTO-BW

I did not understand how to use cmdline.txt

DFS is Dynamic Frequency Selection (radar detection and avoidance), and AUTO-BW is Auto Bandwidth (choose a sensible channel width - 20, 40, 80).

Edit cmdline.txt with your favourite editor - sudo nano /boot/cmdline.txt, sudo vi /boot/cmdline.txt; append brcmfmac.debug=0x100000 to the end of the line, then reboot.

I cannot deactivate a band, but I can change the ssid. I just tested, and the pi4 still connects on the 2,4Ghz band and does not detect the AP in 5Ghz band.

i added the brcmfmac.debug=0x100000 , reboot and voila

$ dmesg | grep brcm
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:62:C5:BF vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=0c282079-02 rootfstype=ext4 cgroup_enable=cpuset cgroup_enable=memory swapaccount=1 elevator=deadline fsck.repair=yes rootwait brcmfmac.debug=0x100000
[    0.267006] brcm-pcie fd500000.pcie: dmabounce: initialised - 32768 kB, threshold 0x00000000c0000000
[    0.267053] brcm-pcie fd500000.pcie: could not get clock
[    0.267130] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[    0.267182] brcm-pcie fd500000.pcie:   MEM 0x600000000..0x603ffffff -> 0xf8000000
[    0.318050] brcm-pcie fd500000.pcie: link up, 5.0 Gbps x1 (!SSC)
[    0.318335] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    0.510242] brcmstb_thermal fd5d2200.thermal: registered AVS TMON of-sensor driver
[    4.258353] brcmfmac: F1 signature read @0x18000000=0x15264345
[    4.275921] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.276607] usbcore: registered new interface driver brcmfmac
[    4.511445] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.515272] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[    4.578457] brcmfmac: CONSOLE: d 0
[    4.578472] brcmfmac: CONSOLE: 000000.063 wl0: Broadcom BCM4345 802.11 Wireless Controller 7.45.202 (r724630 CY)
[    4.578483] brcmfmac: CONSOLE: 000000.064 TCAM: 256 used: 252 exceed:0
[    4.578494] brcmfmac: CONSOLE: 000000.065 reclaim section 1: Returned 122844 bytes to the heap
[    4.578504] brcmfmac: CONSOLE: 000000.065 reclaim section 4: Returned 44 bytes to the heap
[    4.578514] brcmfmac: CONSOLE: 000000.065 sdpcmd_dpc: Enable
[    4.578524] brcmfmac: CONSOLE:
[    4.578534] brcmfmac: CONSOLE: 000000.079 wl0: unable to find iovar "rsdb_mode"
[    4.578545] brcmfmac: CONSOLE: 000000.079 wl0: wlc_iovar_op: rsdb_mode BCME -23 (Unsupported)
[    6.818566] brcmfmac: CONSOLE: 000002.356 wl0: unable to find iovar "toe_ol"
[    6.818579] brcmfmac: CONSOLE: 000002.356 wl0: wlc_iovar_op: toe_ol BCME -23 (Unsupported)
[    6.818589] brcmfmac: CONSOLE: 000002.356 wl0: wl_open
[    6.818600] brcmfmac: CONSOLE: 000002.365 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[    6.826553] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[    6.970542] brcmfmac: brcmf_cfg80211_reg_notifier: Firmware rejected country setting
[    6.988385] brcmfmac: CONSOLE: 000002.526 wl0: wlc_iovar_op: country BCME -2 (Bad Argument)
[    9.578379] brcmfmac: CONSOLE: 000005.110 wl0: wl_open
[    9.578392] brcmfmac: CONSOLE: 000005.119 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[   15.828373] brcmfmac: CONSOLE: 000011.330 wl0: link up (wl0)
[   15.878370] brcmfmac: CONSOLE: 000011.378 wl0: unable to find iovar "nd_hostip_clear"
[   15.878383] brcmfmac: CONSOLE: 000011.378 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)
[   17.248369] brcmfmac: CONSOLE: 000012.745 wl0: unable to find iovar "nd_hostip_clear"
[   17.248382] brcmfmac: CONSOLE: 000012.745 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)

[ 6.970542] brcmfmac: brcmf_cfg80211_reg_notifier: Firmware rejected country setting

That is to be expected with the 813-byte blob. You should get different results with the original 14036-byte blob.

with the original :+1:

$ dmesg | grep brcm
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:62:C5:BF vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=0c282079-02 rootfstype=ext4 cgroup_enable=cpuset cgroup_enable=memory swapaccount=1 elevator=deadline fsck.repair=yes rootwait brcmfmac.debug=0x100000
[    0.269420] brcm-pcie fd500000.pcie: dmabounce: initialised - 32768 kB, threshold 0x00000000c0000000
[    0.269468] brcm-pcie fd500000.pcie: could not get clock
[    0.269542] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[    0.269594] brcm-pcie fd500000.pcie:   MEM 0x600000000..0x603ffffff -> 0xf8000000
[    0.328156] brcm-pcie fd500000.pcie: link up, 5.0 Gbps x1 (!SSC)
[    0.328439] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    0.521831] brcmstb_thermal fd5d2200.thermal: registered AVS TMON of-sensor driver
[    4.221393] brcmfmac: F1 signature read @0x18000000=0x15264345
[    4.229180] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.229548] usbcore: registered new interface driver brcmfmac
[    4.464346] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.480291] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[    4.549788] brcmfmac: CONSOLE: d 0
[    4.549802] brcmfmac: CONSOLE: 000000.063 wl0: Broadcom BCM4345 802.11 Wireless Controller 7.45.202 (r724630 CY)
[    4.549813] brcmfmac: CONSOLE: 000000.064 TCAM: 256 used: 252 exceed:0
[    4.549824] brcmfmac: CONSOLE: 000000.065 reclaim section 1: Returned 122844 bytes to the heap
[    4.549835] brcmfmac: CONSOLE: 000000.065 reclaim section 4: Returned 44 bytes to the heap
[    4.549845] brcmfmac: CONSOLE: 000000.065 sdpcmd_dpc: Enable
[    4.549855] brcmfmac: CONSOLE:
[    4.549865] brcmfmac: CONSOLE: 000000.091 wl0: unable to find iovar "rsdb_mode"
[    4.549875] brcmfmac: CONSOLE: 000000.091 wl0: wlc_iovar_op: rsdb_mode BCME -23 (Unsupported)
[    6.818814] brcmfmac: CONSOLE: 000002.402 wl0: unable to find iovar "toe_ol"
[    6.818828] brcmfmac: CONSOLE: 000002.403 wl0: wlc_iovar_op: toe_ol BCME -23 (Unsupported)
[    6.818838] brcmfmac: CONSOLE: 000002.403 wl0: wl_open
[    6.818849] brcmfmac: CONSOLE: 000002.412 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[    6.825101] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[    9.228528] brcmfmac: CONSOLE: 000004.808 wl0: wl_open
[    9.228541] brcmfmac: CONSOLE: 000004.817 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[   14.448487] brcmfmac: CONSOLE: 000010.004 wl0: link up (wl0)
[   14.588470] brcmfmac: CONSOLE: 000010.140 wl0: unable to find iovar "nd_hostip_clear"
[   14.588484] brcmfmac: CONSOLE: 000010.141 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)
[   14.608519] brcmfmac: CONSOLE: 000010.160 wl0.0: wlc_send_bar: seq 0x1 tid 7
[   15.468485] brcmfmac: CONSOLE: 000011.015 wl0.0: wlc_send_bar: seq 0x3 tid 0
[   16.608490] brcmfmac: CONSOLE: 000012.159 wl0: unable to find iovar "nd_hostip_clear"
[   16.608503] brcmfmac: CONSOLE: 000012.159 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)
[   72.698478] brcmfmac: CONSOLE: 000068.116 wl0.0: wlc_send_bar: seq 0x1 tid 4
[   74.818403] brcmfmac: CONSOLE: 000070.217 wl0.0: wlc_send_bar: seq 0x1 tid 5
[   87.078567] brcmfmac: CONSOLE: 000082.416 wl0.0: wlc_send_bar: seq 0x1 tid 2
[   87.518720] brcmfmac: CONSOLE: 000082.847 wl0.0: wlc_send_bar: seq 0x1 tid 6

I see the 👍 - does that mean it connects to the AC band?

with the original brcm, pi4 (red-bird) is connected on 5Ghz band, but on N, not on AC

$  iw wlan0 scan | grep -A5 'freq: 5'
        freq: 5600
        beacon interval: 96 TUs
        capability: ESS Privacy SpectrumMgmt (0x0111)
        signal: -52.00 dBm
        last seen: 0 ms ago
        SSID: *** //ap on 5G

Thanks - I understand.

i relaunch and examine the two frequencies of my AP

5600 MHz [120]
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 940 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 940 sec)
          DFS CAC time: 60000 ms

the channel with config of 80Mhz (VHT80) is not present !! Only 20MHz an HT40+.
Could it come from there? How to add it to the config?

The old blob doesn't declare any VHT-80 channels, and causes other problems for some regions (KR, for example). The new mini-blob should help with many of those problems, but for some reason it is not working for you.

can the channel code 'fr' be the cause (with new mini blob) ? should i test with another code?

As I understand it, the mini-blob should reject all country codes and learn from the environment. You can try a different CC, but it should make no difference.

[ 6.970542] brcmfmac: brcmf_cfg80211_reg_notifier: Firmware rejected country setting

country=fr

inside your wpa_supplicant.conf, should not it be capitalized as country=FR rather than country=fr?

country=fr or country=FR ore country=US are same reg

$ iw reg get
global
country FR: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
        (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

BUT with country=US, it's work on 5Ghz mode AC !!!!! With the same ssid for two bands..

the final configuration

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
wireless-power off
iface default inet dhcp

country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid="matrice"
psk="*********"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}

$ iwconfig
eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:"matrice"
          Mode:Managed  Frequency:5.6 GHz  Access Point: *****
          Bit Rate=433.3 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=70/70  Signal level=-23 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ iw dev
phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr ***
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr ***
                ssid *****
                type managed
                channel 120 (5600 MHz), width: 80 MHz, center1: 5610 MHz
                txpower 31.00 dBm

While country=US makes it capable to connect to "ac-only" mode AP and iw shows width: 80MHz, the actual speed is not at all faster (well, maybe at most 5%). It's still capped at ~100Mbps, while my buffalo/realtek 1x1/433 ac usb 2.0 receiver is 2.5 times faster.

I can't help but notice a difference:

[tom@alarmpi tmp]$ iw phy phy0 info | grep highest
        VHT RX highest supported: 0 Mbps
        VHT TX highest supported: 0 Mbps
[tom@alarmpi tmp]$ iw phy phy1 info | grep highest
        VHT RX highest supported: 434 Mbps
        VHT TX highest supported: 434 Mbps

The 43455 is connected over a 4-bit SDIO link usually running at ~42MHz. That gives a theoretical throughput limit of 168Mbps, but that is half-duplex and assuming no commands and no pauses. Given that, ~100Mbps is about what I would expect.

The 43455 is connected over a 4-bit SDIO link usually running at ~42MHz. That gives a theoretical throughput limit of 168Mbps, but that is half-duplex and assuming no commands and no pauses. Given that, ~100Mbps is about what I would expect.

lol, so ac or not is not supposed to matter anyway? (other than "compatibility") imo the foundation should state that cap :P

An individual Pi may not be able to max out the AC bandwidth, but each packet will be sent at full rate which will leave larger gaps for others to transmit in - there is an advantage.

There's now an updated clm_blob that should give access to the 80MHz channels: https://drive.google.com/file/d/1AN7lC_kMJGGg5AJLhSRtlTRgIh9qJlaI/view?usp=sharing
This is the result using country code FR:

pi@raspberrypi:~$ iw phy0 channels
Band 1:
        * 2412 MHz [1]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2417 MHz [2]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2422 MHz [3]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2427 MHz [4]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2432 MHz [5]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2437 MHz [6]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2442 MHz [7]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2447 MHz [8]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2452 MHz [9]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2457 MHz [10]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2462 MHz [11]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2467 MHz [12]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2472 MHz [13]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2484 MHz [14] (disabled)
Band 2:
        * 5170 MHz [34] (disabled)
        * 5180 MHz [36]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5190 MHz [38] (disabled)
        * 5200 MHz [40]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5210 MHz [42] (disabled)
        * 5220 MHz [44]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5230 MHz [46] (disabled)
        * 5240 MHz [48]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 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 HT40+ VHT80
        * 5765 MHz [153]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5785 MHz [157]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5805 MHz [161]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5825 MHz [165]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz

Might be worth announcing this on the forum.

See https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=291609.

@graysky2 Would you take over https://github.com/archlinuxarm/PKGBUILDs/tree/master/alarm/firmware-raspberrypi? Also see https://archlinuxarm.org/forum/viewtopic.php?f=15&t=14684

@tomty89 - I don't know how wise it is to ship these untested. Plus, including these is ultimately up to @kmihelich

@pelwell Can you give me a hint on how to install the blob?
In https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=291609 I see instructions for copying brcmfmac43455-sdio.clm_blob to /lib/firmware/brcm/.
But the given downloadlink points to brcmfmac43455-sdio.bin. Where do I get the .clm_blob file from?

I don't understand - the download link (https://drive.google.com/file/d/1AN7lC_kMJGGg5AJLhSRtlTRgIh9qJlaI/view?usp=sharing) is for brcmfmac43455-sdio.clm_blob.

OK, my fault. FireFox for Android replaced the file extension from clm_blob to bin for some reason.

Thanks for the hint to the firmware blob!
In a quick test the Raspberry Pi was able to establish a connection to my FRITZ!Box with region DE & WIFI standard AC & HT80.
I will try to make some stability tests.

At this point it is looking very likely that the updated blob will be in the next image.

I cheered too soon. The Raspberry PI is now only able to connect to APs that use channels lower than 52 which are only channels 36, 40, 44 and 48. APs on different channels are not seen/found by the Raspberry PI.

iw reg get:
global
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

It does not matter which country I configure in wpa_supplicant.conf. I tried DE, US and UG.

Try this one instead: https://drive.google.com/file/d/1J8DdbsrZcSkDYKUPsdy2RvncttSwQdBH/view?usp=sharing

Note that you will need to rename it from brcmfmac43456-sdio.clm_blob to brcmfmac43455-sdio.clm_blob before (or when) copying it /lib/firmware/brcm.

Thanks pelwell. I did some testing and set up a comparison between original, 43455 and 34456 blob.
I put the negative points in bold.

original blob:

• ac and HT80 is not possible
• connection to all 5 GHz channels is possible
• connection to all 2,4 GHz channels is possible

brcmfmac43455-sdio.clm_blob:

• ac connection with HT80 is possible
• 5 GHz connection is only possible with channels 36, 40, 44 and 48
• 2,4 GHz connection is possible with all channels 1 to 13

brcmfmac43456-sdio.clm_blob:

• ac connection with HT80 is possible
• 5 GHz connection seems to be possible with all channels (I tested some random channels like 36, 52, 64, 100, 116, 128)
• 2,4 GHz connection is only possible with channels 1 and 2

• 2,4 GHz connection is only possible with channels 1 and 2

I have a Pi 4 here running with the renamed 43455 clm_blob, configured to be in WiFi region "DE", and it's happily connected on channel 11.

Well strange, I put a second Pi 4 in my testsetup and this one can connect with all 2,4 GHz channels.
Although I'm a bit puzzled as to why the first Pi is having problems, the brcmfmac43456-sdio.clm_blob fixes the ac problem.

You said that the updated blob will be in the next image. Do you have a clue, when this will be released? Or can you say when the blob will be part of regular updates via apt?

The next image is due in a matter of weeks, rather than months. The relevant apt package might be updated before then, but probably not.