AC mode on Raspberry Pi 4 WiFi

Hello

I am using a quite recent snapshot from last week, but I cannot make the onboard WiFi to work
Once I enable it, in AC mode with a quite normal channel (40) it gives me in dmesg:

[  701.044449] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  707.046697] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  713.068313] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  719.089760] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  725.111944] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  731.133385] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  737.154405] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  743.176111] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  749.198835] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  755.220854] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  761.241862] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52
[  767.263849] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=58154, -52

Then if I try to change something in the configuration, it mess up wpad, I loose my other USB wifi and the onboard AC turn in client mode:

[  770.814116] ieee80211 phy0: brcmf_run_escan: error (-52)
[  770.819512] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-52)
[  771.341068] br-lan: port 2(wlan0) entered disabled state
[  771.352759] device wlan0 left promiscuous mode
[  771.357275] br-lan: port 2(wlan0) entered disabled state
[  771.393637] ieee80211 phy0: brcmf_run_escan: error (-52)
[  771.399069] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-52)

then I need to restart. I have set country code to IT in raspbian before using openwrt
I have found another post from last year Raspberry pi 4 access point where an user succeeded with N mode, so I am wondering if there is still the issue or someone could make it work

Thanks for the help!

there is an issue, but can be made to work...

[root@rpi 52°]# iw wlan0 info
Interface wlan0
	ifindex 57
	wdev 0x1
	addr ab:cd:ef:12:34:56
	ssid pi40
	type AP
	wiphy 0
	channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
	txpower 31.00 dBm

[root@rpi 53°]# iwinfo wlan0 assoclist
12:34:56:65:43:21  -54 dBm / -89 dBm (SNR 35)  0 ms ago
	RX: 150.0 MBit/s                                8023 Pkts.
	TX: 150.0 MBit/s                               29043 Pkts.

I would have believed you :wink: Good, but what is the correct config to use?

#!/bin/sh

echo "please be patient this can take 1min+"

cat <<'EOF' > /tmp/hostapd-40-a.conf
interface=wlan0
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
driver=nl80211
channel=36
macaddr_acl=0
wmm_enabled=1
obss_interval=300
ht_capab=[HT40+][SHORT-GI-20][DSSS_CCK-40]
ieee80211ac=1
vht_oper_chwidth=0
vht_capab=[SHORT-GI-80][SU-BEAMFORMEE]
beacon_int=50
dtim_period=20
basic_rates=180 240 360 480 540
disassoc_low_ack=0
ssid=pi40
bridge=br-lan
hw_mode=a
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=turtle23
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
EOF

kill -9 $(pidof hostapd) 2>/dev/null; sleep 7
/etc/init.d/wpad disable; /etc/init.d/wpad stop
ifconfig wlan0 down; sleep 3
/usr/sbin/hostapd -s -d -B /tmp/hostapd-40-a.conf

So it cannot make to work with standard UCI/LUCI so far

My Raspberry Pi 4 only works with this setting for AC mode

1 Like

I tried channel 100 but I did not try Width 20Mhz

I had tried 80Mhz and 40Mhz and doesn't work.

What is the reasoning we need a custom hostapd configuration?

Which specific items did you change?

Why does this only seem to affect Pi devices (maybe only the Pi 4)?

In my case - I'm not trying to set up an AP, I'm trying to connect as a client to a network running HT80. Even after pulling the regdb and BCM43455 firmware/nvram files from a Pi 4 running Ubuntu 20.04 (which connects to that HT80 network with no issue at all, indicating that the hardware is fully capable), HT80 networks are hidden from scan results and can't be connected to.

As to why I pulled the regdb - at least on the Pi 4, the regdb for the US country code that is put onto the filesystem by OpenWRT is erroneous. The most obvious indicator of this is that channels above 11 are allowed with OpenWRT's regdb in the US, but channels above 11 are disallowed in the regdb I pulled from the Pi 4 running Ubuntu as is expected in the US.

preface: i've only experimented with ap modes...

my theory is... it all comes down to how 80211.sh handles the limited capabilities of the rpi4...

it enumerates as HT80, which while possible to operate in this mode... as demonstrated above... the 80211.sh handler then uses this value to derive other specific values... that for the pi... are in some ways too specific and in other ways not specific enough...

for the underlying determinism's, forcing 40... goes half way to resolution... the other catch's lie in country, dfs and mode coherency...

whether you think you need something or not is your determination. the info provided was merely to demonstrate capability as a proof of concept.

Yeah, I'm hoping to find root cause here so that OpenWRT itself can be patched.

Edit: By 80211.sh handler, do you mean /lib/wifi/mac80211.sh, /lib/netifd/mac80211.sh, or /lib/netifd/wireless/mac80211.sh?

Gotta love three scripts with the same name that are clearly different. :frowning:

1 Like

lol had to look myself good thing i had saved the path :clown_face:

well if it's of any use... playing around with '/lib/netifd/wireless/mac80211.sh' my current iteration hardcodes;

  • no g
  • enumerate as VHT40
  • kick wpad on wifi up / down
  • probably some dfs params
    then in config
  • force 40 / ac / 40
  • define country ( *** there is alot of verbosity from the driver about this *** )

this reliably gets me master mode ac... without it, dfs probing spits the dummy and it keels over into 'client'... it only ''likes" one channel ( AU 36 ) and the probing routine doesn't always enumerate it cleanly ( which may come from the section after 80211 selects 80/40 then calculates the channel widths - if not that, it's probably the buggy country stuff or both :woozy_face: ).

Ah, OK, so you customized that one.

Do you have a copy somewhere in a git repo that doesn't require grabbing a whole build to extract one file? :slight_smile:
I'm looking at differences between what iw list and iw phy phyN info report between my Pi4 and my C2600.

I'm wondering if there's a possibility that there's a corner case where a device that does dual bands in one chip behaves badly in OpenWRT - quite a few of the dualband OpenWRT routers (every one I've worked with, but I'm guessing there are exceptions) have separate PHYs for 2.4 and 5 - the Pi4 only has one dualband PHY.

yeah that sounds close... or the fact that the number of channels per band is quirky.. simple case of what the card reports itself as is more limited than what OpenWrt would expect from a device that reports itself as such :flushed:

best thing to do is just run a few distros and pluck the derived configs / cmd outputs... you'll have your answer soon enough...

my sample is (working :nerd_face: barely)freestyle rubbish

Yup. I'll diff what you have against upstream to get a sense of where the problems are.

I'm trying to figure out what actually calls that script so I can see the data that is passed here:

init_wireless_driver "$@"

thinking about it some more...

the C stuff ( cfg80211.ko )... is just if not more a likely cantidate... why else would the thing start scanning and dump itself back to client mode...

i.e.;

cat /sys/kernel/debug/ieee80211/phy0/ht40allow_map

haven't been using the buildroot much for the pi... but spinning up a full debug image of the above might be worth a shot ( failing the pro's weighing in )

It seems unlikely it's the kernel modules - there's little to no difference between mainline and what Ubuntu runs on a Pi 4 at this point for cfg80211 along with brcmfmac, and at least

iw phy phy0 info

gives nearly identical results other than some small countrycode oddities - and those disappear (but our problems do not) if you copy a regdb from an Ubuntu machine.

I'm wondering if netifd has some code I haven't found that adds .sh to certain items automatically which is why grepping for "mac80211.sh" doesn't result in much that is useful.

1 Like

hmmm... well my modded 80211.sh is no good today...

either way... show some insight... some random errs...

[ 2644.501258] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52
[ 2650.524544] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52

#Fri Aug  7 17:44:07 2020 daemon.notice netifd: radio0 (8955): + iw phy phy0 set txpower auto
#Fri Aug  7 17:44:07 2020 daemon.notice netifd: radio0 (8955): command failed: I/O error (-5)
#Fri Aug  7 17:44:07 2020 daemon.notice netifd: radio0 (8955): + '[' -n  ]


No force 40 and b rates on ( default )

Fri Aug  7 18:35:19 2020 kern.info kernel: [ 4390.387121] device wlan0 entered promiscuous mode
Fri Aug  7 18:35:19 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
*****Fri Aug  7 18:35:19 2020 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->HT_SCAN
Fri Aug  7 18:35:19 2020 kern.err kernel: [ 4390.393482] ieee80211 phy0: brcmf_run_escan: error (-52)
Fri Aug  7 18:35:19 2020 kern.err kernel: [ 4390.398803] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-52)
Fri Aug  7 18:35:19 2020 kern.info kernel: [ 4390.921464] br-lan: port 2(wlan0) entered disabled state
Fri Aug  7 18:35:19 2020 kern.info kernel: [ 4390.930863] device wlan0 left promiscuous mode
Fri Aug  7 18:35:19 2020 kern.info kernel: [ 4390.935510] br-lan: port 2(wlan0) entered disabled state
Fri Aug  7 18:35:19 2020 kern.err kernel: [ 4390.963329] ieee80211 phy0: brcmf_run_escan: error (-52)
Fri Aug  7 18:35:19 2020 kern.err kernel: [ 4390.968801] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-52)
Fri Aug  7 18:35:19 2020 daemon.err hostapd: Failed to request a scan of neighboring BSSes ret=-52 (No error information)
******Fri Aug  7 18:35:19 2020 daemon.notice hostapd: wlan0: interface state HT_SCAN->DISABLED
Fri Aug  7 18:35:19 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Fri Aug  7 18:35:19 2020 daemon.err hostapd: wlan0: Unable to setup interface.
Fri Aug  7 18:35:19 2020 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Fri Aug  7 18:35:19 2020 daemon.notice hostapd: nl80211: Failed to remove interface wlan0 from bridge br-lan: Invalid argument
Fri Aug  7 18:35:20 2020 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Fri Aug  7 18:35:20 2020 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Fri Aug  7 18:35:20 2020 daemon.notice netifd: radio0 (13342): Command failed: Invalid argument
Fri Aug  7 18:36:03 2020 daemon.notice netifd: radio0 (13507): Command failed: Invalid argument
Fri Aug  7 18:36:04 2020 daemon.notice netifd: radio0 (13507): command failed: No error information (-524)
Fri Aug  7 18:36:04 2020 daemon.notice netifd: radio0 (13522): command failed: No error information (-524)
Fri Aug  7 18:36:04 2020 daemon.notice netifd: radio0 (13522): command failed: I/O error (-5)
Fri Aug  7 18:36:09 2020 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Fri Aug  7 18:36:09 2020 kern.info kernel: [ 4440.089994] br-lan: port 2(wlan0) entered blocking state
Fri Aug  7 18:36:09 2020 kern.info kernel: [ 4440.095335] br-lan: port 2(wlan0) entered disabled state


force 40 and b rates off

Fri Aug  7 18:36:09 2020 kern.info kernel: [ 4440.100813] device wlan0 entered promiscuous mode
Fri Aug  7 18:36:09 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
********Fri Aug  7 18:36:09 2020 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->ENABLED
Fri Aug  7 18:36:09 2020 daemon.notice hostapd: wlan0: AP-ENABLED
Fri Aug  7 18:36:09 2020 kern.err kernel: [ 4440.110978] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52
Fri Aug  7 18:36:15 2020 kern.err kernel: [ 4446.119866] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52
Fri Aug  7 18:36:16 2020 daemon.notice hostapd: Remove interface 'wlan0'
Fri Aug  7 18:36:16 2020 daemon.notice hostapd: wlan0: interface state ENABLED->DISABLED
Fri Aug  7 18:36:16 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Fri Aug  7 18:36:16 2020 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Fri Aug  7 18:36:16 2020 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Fri Aug  7 18:36:16 2020 kern.info kernel: [ 4447.958343] device wlan0 left promiscuous mode
Fri Aug  7 18:36:16 2020 kern.info kernel: [ 4447.962908] br-lan: port 2(wlan0) entered disabled state
Fri Aug  7 18:36:17 2020 daemon.notice netifd: radio0 (13696): command failed: No error information (-524)
Fri Aug  7 18:36:17 2020 daemon.notice netifd: radio0 (13714): command failed: No error information (-524)
Fri Aug  7 18:36:17 2020 daemon.notice netifd: radio0 (13714): command failed: I/O error (-5)
Fri Aug  7 18:36:22 2020 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Fri Aug  7 18:36:22 2020 kern.info kernel: [ 4453.570751] br-lan: port 2(wlan0) entered blocking state
Fri Aug  7 18:36:22 2020 kern.info kernel: [ 4453.576100] br-lan: port 2(wlan0) entered disabled state
Fri Aug  7 18:36:22 2020 kern.info kernel: [ 4453.581558] device wlan0 entered promiscuous mode
Fri Aug  7 18:36:22 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Fri Aug  7 18:36:22 2020 kern.err kernel: [ 4453.591575] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52
Fri Aug  7 18:36:22 2020 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->ENABLED
Fri Aug  7 18:36:22 2020 daemon.notice hostapd: wlan0: AP-ENABLED
Fri Aug  7 18:36:28 2020 kern.err kernel: [ 4459.600639] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52
Fri Aug  7 18:36:34 2020 kern.err kernel: [ 4465.622565] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52


EDIT: b rates on has no effect... so it's only the force 40... and something to do with how that influences initialisation

There is a note in the rtl8812ac driver from aircrack-ng that says the driver has trouble with the way openwrt create and destroy wlan interface on bring up.
This driver has the same problematic behaviour of the rpi4 broadcom driver.
Maybe it is somehow related

2 Likes

Oh, useful info there!

As to what is calling mac80211.sh - it looks like netifd traverses /lib/netifd to find all .sh scripts:

https://git.openwrt.org/?p=project/netifd.git;a=blob;f=handler.c;h=8608a9751ea9f5705b182b762cb0a9b5b8090852;hb=HEAD

Enabling netfid debug output is likely to be useful

Edit: I'm getting debug info out of netifd, unfortunately right now I'm not located at my VHT80 test location, VHT20 is working fine where I am. Although it's not seeing some APs on channel 153 that my Android phone can see, I'm not sure if this is due to signal strength or is related to our issue.

When I get to my VHT80 test location I'll drop that AP down to a lower channel to see what happens.

Edit: At least as a client, VHT40 in lower channels works, when I looked at wifianalyzer on my phone I noticed they were running at least VHT40 and editing the config in LuCi to match that works.

Edit 2: Never mind, setting VHT40 seems to cause an I/O error from the driver, but it still connects fine, just at VHT20 instead
Edit 3: Maybe just HT20... A GL-AR750S on the same network reports:

135.0 Mbit/s, 40 MHz, MCS 6, Short GI
150.0 Mbit/s, 40 MHz, MCS 7, Short GI

The Pi reports:

150.0 Mbit/s, 20 MHz
200.0 Mbit/s, 20 MHz

No MCS or GI information - I'm not sure exactly what that means

Edit 4: But

iw dev wlan0 info

returns a channel width of 40 MHz?

1 Like