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:
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
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.
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.
lol had to look myself good thing i had saved the path
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 ).
Do you have a copy somewhere in a git repo that doesn't require grabbing a whole build to extract one file?
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
best thing to do is just run a few distros and pluck the derived configs / cmd outputs... you'll have your answer soon enough...
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...
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.
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
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
Good, but what is the correct config to use?
).
barely)freestyle