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

DrHardReset · 2019-12-16T17:16:58Z

The Raspberry Pi 4 is not able to connect to wifi accesspoints with wifi standard "ac".
This is because the Raspberry PI 4 is not sending any VHT Capabilities.
My wifi router is running with 5 GHz mixed standard "n+ac" (WI-Fi 5) accesspoint and the Raspberry PI 4 is always connecting with n standard.

To reproduce
Use the following wpa_supplicant config and connect to accesspoint.

wpa_supplicant.config:

ctrl_interface=/run/wpa_supplicant
p2p_disabled=1

network={
ssid="MySSID"
psk="MySecurePsk"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
pbss=2
}

Expected behaviour
The Raspberry PI 4 should send VHT Capabilities and connect with wifi standard ac

Actual behaviour
The Raspberry PI 4 does not send VHT Capabilities and connects with wifi standard n

Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
Raspberry Pi 4 4 GB RAM
Which OS and version (cat /etc/rpi-issue)?
Raspberry Pi reference 2019-06-08
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, d942d5487c035ecd568c1a3049d8b00b14132678, stage5
Which firmware version (vcgencmd version)?
Sep 24 2019 17:34:30
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)
Which kernel version (uname -a)?
Linux hostname 4.19.75-v7l+ solved issue of mirroring screen after rotation. #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

Logs
Find attached a Wireshark capture of the association request with missing VHT Capabilities...
wireshark_capture.zip

dmesg:
dmesg.txt

The text was updated successfully, but these errors were encountered:

pelwell · 2019-12-16T17:32:18Z

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

DrHardReset · 2019-12-16T19:53:21Z

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.

pelwell · 2019-12-17T10:17:22Z

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:

Most ac APs don't require VHT capabilities, but yours does.
No ac APs require VHT capabilities - the failure to connect to your AP is caused by something else.
Most 43455-equipped Pis generate VHT capabilities, but your 4B with your configuration doesn't.
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.

ghost · 2019-12-17T17:31:45Z

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

pelwell · 2019-12-17T17:34:49Z

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?

DrHardReset · 2019-12-18T15:47:39Z

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"?

pelwell · 2019-12-18T16:25:32Z

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.

DrHardReset · 2019-12-20T19:05:21Z

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".

satmandu · 2019-12-20T20:13:03Z

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

zorazor · 2020-04-12T01:27:57Z

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)

DrHardReset · 2020-04-14T14:05:13Z

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

kosmosgit · 2020-04-19T19:48:25Z

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

DrHardReset · 2020-04-29T13:12:48Z

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

pelwell · 2020-06-16T15:21:27Z

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.

fpousserot · 2020-06-18T14:52:56Z

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

pelwell · 2020-06-18T15:02:37Z

What does iw phy0 channels report?

fpousserot · 2020-06-18T15:14:18Z

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

pelwell · 2020-06-18T15:18:16Z

And how about iwconfig wlan0 and iw reg get?

fpousserot · 2020-06-18T15:21:38Z

$ 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

fpousserot · 2020-06-18T15:23:58Z

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

pelwell · 2020-06-18T15:25:54Z

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

fpousserot · 2020-06-18T15:29:03Z

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

pelwell · 2020-06-18T15:34:11Z

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.

fpousserot · 2020-06-18T15:46:39Z

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

fpousserot · 2020-06-18T15:49:01Z

I did not understand how to use cmdline.txt

pelwell · 2020-06-18T15:53:50Z

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

pelwell · 2020-06-18T15:55:13Z

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.

fpousserot · 2020-06-18T16:06:53Z

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)

fpousserot · 2020-06-18T16:09:03Z

[ 6.970542] brcmfmac: brcmf_cfg80211_reg_notifier: Firmware rejected country setting

pelwell · 2020-06-18T16:12:49Z

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

pelwell · 2020-06-18T16:27:31Z

Thanks - I understand.

fpousserot · 2020-06-18T16:34:39Z

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?

pelwell · 2020-06-18T16:37:41Z

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.

fpousserot · 2020-06-18T16:40:50Z

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

pelwell · 2020-06-18T16:49:36Z

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.

macmpi · 2020-06-18T17:27:31Z

[ 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?

fpousserot · 2020-06-18T18:19:45Z

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

tomty89 · 2020-08-14T16:42:31Z

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

pelwell · 2020-08-14T16:51:03Z

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.

tomty89 · 2020-08-14T17:07:33Z

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

pelwell · 2020-08-14T17:11:09Z

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.

pelwell · 2020-11-18T12:17:19Z

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

JamesH65 · 2020-11-18T14:30:49Z

Might be worth announcing this on the forum.

pelwell · 2020-11-18T15:08:47Z

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

tomty89 · 2020-11-20T02:27:42Z

@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

graysky2 · 2020-11-20T12:05:41Z

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

DrHardReset · 2020-11-26T10:49:47Z

@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?

pelwell · 2020-11-26T10:52:31Z

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

DrHardReset · 2020-11-26T11:21:10Z

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

DrHardReset · 2020-11-26T13:38:31Z

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.

pelwell · 2020-11-26T13:44:47Z

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

DrHardReset · 2020-11-27T07:37:44Z

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.

pelwell · 2020-11-27T09:24:34Z

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.

DrHardReset · 2020-11-30T16:01:49Z

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

pelwell · 2020-11-30T16:11:14Z

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.

DrHardReset · 2020-11-30T18:46:37Z

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?

pelwell · 2020-11-30T19:04:29Z

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.

DrHardReset · 2021-04-12T14:11:30Z

With the latest build from https://downloads.raspberrypi.org/raspios_armhf/images/raspios_armhf-2021-03-25/2021-03-04-raspios-buster-armhf.zip the PI can connect using "ac" as expected.

pelwell added the Wifi Issue Any issues related to wifi label Nov 18, 2020

DrHardReset closed this as completed Apr 12, 2021

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

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

Comments

DrHardReset commented Dec 16, 2019

pelwell commented Dec 16, 2019

DrHardReset commented Dec 16, 2019 • edited

pelwell commented Dec 17, 2019

ghost commented Dec 17, 2019

pelwell commented Dec 17, 2019

DrHardReset commented Dec 18, 2019 • edited

pelwell commented Dec 18, 2019

DrHardReset commented Dec 20, 2019

satmandu commented Dec 20, 2019 • edited

zorazor commented Apr 12, 2020 • edited

DrHardReset commented Apr 14, 2020

kosmosgit commented Apr 19, 2020

DrHardReset commented Apr 29, 2020

pelwell commented Jun 16, 2020

fpousserot commented Jun 18, 2020 • edited

pelwell commented Jun 18, 2020

fpousserot commented Jun 18, 2020 • edited

pelwell commented Jun 18, 2020

fpousserot commented Jun 18, 2020

fpousserot commented Jun 18, 2020

pelwell commented Jun 18, 2020

fpousserot commented Jun 18, 2020

pelwell commented Jun 18, 2020

fpousserot commented Jun 18, 2020

fpousserot commented Jun 18, 2020

pelwell commented Jun 18, 2020

pelwell commented Jun 18, 2020

fpousserot commented Jun 18, 2020

fpousserot commented Jun 18, 2020

pelwell commented Jun 18, 2020

pelwell commented Jun 18, 2020

fpousserot commented Jun 18, 2020

pelwell commented Jun 18, 2020

fpousserot commented Jun 18, 2020

pelwell commented Jun 18, 2020

macmpi commented Jun 18, 2020

fpousserot commented Jun 18, 2020 • edited

tomty89 commented Aug 14, 2020

pelwell commented Aug 14, 2020

tomty89 commented Aug 14, 2020 • edited

pelwell commented Aug 14, 2020

pelwell commented Nov 18, 2020

JamesH65 commented Nov 18, 2020

pelwell commented Nov 18, 2020

tomty89 commented Nov 20, 2020

graysky2 commented Nov 20, 2020

DrHardReset commented Nov 26, 2020

pelwell commented Nov 26, 2020

DrHardReset commented Nov 26, 2020

DrHardReset commented Nov 26, 2020

pelwell commented Nov 26, 2020

DrHardReset commented Nov 27, 2020

pelwell commented Nov 27, 2020

DrHardReset commented Nov 30, 2020

pelwell commented Nov 30, 2020

DrHardReset commented Nov 30, 2020

pelwell commented Nov 30, 2020

DrHardReset commented Apr 12, 2021

DrHardReset commented Dec 16, 2019 •

edited

DrHardReset commented Dec 18, 2019 •

edited

satmandu commented Dec 20, 2019 •

edited

zorazor commented Apr 12, 2020 •

edited

fpousserot commented Jun 18, 2020 •

edited

fpousserot commented Jun 18, 2020 •

edited

fpousserot commented Jun 18, 2020 •

edited

tomty89 commented Aug 14, 2020 •

edited