An additional bit of information:
The inability to see my home router is definitely a frequency issue. For some reason, higher channels are not seen in the scan results despite the countrycode being set to US and an updated regdb that (at least) gives sensible results from
iw phy phy0 info
Obviously it doesn't work with the old regdb either. I've seen reports that on some OSes (wasn't the case for my Ubuntu unit) you need to set the countrycode in Raspbian first for some strange reason.
yeah... that hack above to manually get 80 working wanted some manual country set action... pretty sure there is a 'timing/sequencing-setup' thing going on... [in addition to the other capability limitation/matching thing]...
but... there is also a fair chance there is a 'stale state' thing going on in master since a few weeks plus... as well...
so that's 3 finnicky glitches... but the one you mention ( freqs ) is the most pertinent...
"stale state"?
I've tried seting the roamoff parameter when the module is loaded to 0 - no effect. (That is one thing I noticed was different in the Ubuntu kernel)
If you pass a frequency of 5785 (channel 157, which the iw phy info says should be valid, and is valid in the US) when trying to scan using
iw dev wlan0 scan freq 5785
Pass a frequency like 2412 and the freq option takes effect
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 36), (N/A)
(57000 - 66000 @ 2160), (N/A, 43), (N/A), NO-OUTDOOR
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
notice the @80
Yup. Same for my regdb pulled from an Ubuntu installation:
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
But while "iw list" and "iw phy phy0 info" and "iw reg get" give the data you expect, it's almost as if the firmware in the chip is behaving differently.
I can't find anything relevant in the kernel source - it appears that the Ubuntu kernel is not using any of the customizations seen in the raspi.org kernels, and the Ubuntu kernel works well.
yeah... auto >>> set to 20>ok set it to 40>ok ( both 36 )
set to 80 >>>
[ 258.351588] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52
[ 264.375726] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=57386, -52
set it back to 40 >>> crashes into 'client'...
( sure, you expect 80 to be an issue... but not being able to undo that change without re-instantiating the modules is a concern )
related ... i think i owe an apology to the team... these errors are popping up on all platforms spanning back more than a year... but yes... some distro's seem to have found ways to massage things in to submission.... this one goes in the 'time will fix it basket' I think...
Yeah. I'm wondering if the Ubuntu kernel source on raspis is different from the "normally documented" kernel source... Half of Ubuntu's documentation regarding obtaining kernel source is sadly out of date (notably, anything involving apt-get source fails to actually pull down kernel source for me)
The official raspi kernel source does have some patches related to roaming mode and country code changes, although the commit descriptions imply it shouldn't affect an override coming from userspace, just the defaults.
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-raspi/+git/focal/commit/drivers/net/wireless/broadcom/brcm80211?id=321ba7449a30d88ac5b93cae413cc913c3b37fe3 is interesting. The commit message says that it adds support for a device we don't have in a pi4, however:
"brcmfmac: Use original country code as a fallback
Commit 73345fd212980d2e28a5c6d83801c903bd773680:
brcmfmac: Configure country code using device specific settings
prevents region codes from working on devices that lack a region code
translation table. In the event of an absent table, preserve the old
behaviour of using the provided code as-is.
Signed-off-by: Phil Elwell phil@raspberrypi.org"
Sounds a lot like our problem, and the patch touches code that is not specific to a 43341...
they are running firmware:7.45.202 ( vs 206 ) with 43455-pwropt action... must be a reason they haven't bumped...
to be fair... master is master...
I finally got tracing working to potentially see if the missing patches might be relevant, but go figure, it's hard to turn on tracing for the relevant line without causing massive logspam.
I'm getting very tempted to just apply the patches Ubuntu and RPi use and see what happens.
I did determine that scan results are definitely a firmware thing - userspace sends the correct channel list to the device, and the firmware seems to ignore it silently, or if not, there's so much logspam I don't see the error response.
( fyi... the latest master bumped some wireless code )
this looks like a fairly clean init(from boot)... except for the last line or few... didn't see it much yesterday / before... ( ACS scan )
Tue Aug 11 15:34:22 2020 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Tue Aug 11 15:34:22 2020 kern.info kernel: [ 10.085042] br-lan: port 2(wlan0) entered blocking state
Tue Aug 11 15:34:22 2020 kern.info kernel: [ 10.090381] br-lan: port 2(wlan0) entered disabled state
Tue Aug 11 15:34:22 2020 kern.info kernel: [ 10.095821] device wlan0 entered promiscuous mode
Tue Aug 11 15:34:22 2020 daemon.notice hostapd: ACS: Automatic channel selection started, this may take a bit
Tue Aug 11 15:34:22 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->ACS
Tue Aug 11 15:34:22 2020 daemon.notice hostapd: wlan0: ACS-STARTED
Tue Aug 11 15:34:24 2020 daemon.notice hostapd: ACS: Survey is missing channel time
Tue Aug 11 15:34:24 2020 daemon.notice hostapd: ACS: Survey is missing RX and busy time (at least one is required)
Tue Aug 11 15:34:24 2020 daemon.notice hostapd: ACS: Survey is missing channel time
Tue Aug 11 15:34:24 2020 daemon.notice hostapd: ACS: Survey is missing RX and busy time (at least one is required)
Tue Aug 11 15:34:24 2020 daemon.notice hostapd: ACS: Survey is missing channel time
unless it's just a client thing... also some interest background re: cypress clm blobs... also, those guys use rfkill and alternate region code...
Pulling in some of the patches from the rpi kernel sources don't seem to have done anything, unless you have to use both those AND recent blobs from https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm (Nope, using most recent blobs with those patches is failing. Now attempting to set ccode in the nvram text file and crank up tracing...)
That's interesting regarding the firmware blobs - although openwrt does pull in the Cypress distribution by default, not the linux-firmware blobs.
######debian ( lpc_pwropt-43455 )
7.45.202 (r724630 CY) Mar 2 2020 2020-03-02 23:19:15 DVID 01-37031479
##### raspi64 ( lpc_pwropt-43455 )
7.45.202 (r724630 CY) Mar 2 2020 2020-03-02 23:19:15 DVID 01-37031479
### ubuntu not sure which one
43455c0 Version: 7.45.202 (r724630 CY) CRC: 4b9a9ceb Date: Mon 2020-03-02 23:32:43 PST Ucode Ver: 1043.2139 FWID 01-72f6ece2
?> 43455c5-roml 7.84.17.1 (r871554) CRC: 72494685 Date: Thu 2020-05-14 17:41:11 KST Ucode Ver: 1043.20424 FWID: 01-3d9e1d87
### owrt latest -> macbump
7.45.206 (r725000 CY) Mar 23 2020 2020-03-23 02:06:14 DVID 01-2c52dea2
rpi-distro has 206 also, I won't be able to check Ubuntu 20.04 until tonight.
Also, i bumped up LOG_BUF_SHIFT in the kconfig so I can get all of the logspam, and it turns out that my attempts to patch the kernel didn't actually apply... This is the first time I've tried to patch a kernel within OpenWRT's build system. I'm in the process of rebuilding a second attempt now.
I think in my case - it looks like brcmfmac isn't built from the main kernel source, but instead a separate "backports" package. So my patches applied, but the module isn't built from the main kernel source.
Rebuilding the mac80211 backports packages/kmods now
Edit: YEEEEESSSSS! It is one of the upstream patches. I need to head out, I'll put the patch file up tomorrow once I clean things up.
I need to fix up the ocmmit messages for that patch and also the embedded quilt patch, and also I should try and find unsquashed versions of the patch before formally submitting it to the OpenWRT team.
This is a squash of the following commits from raspi's kernel repo:
This fixes support for higher frequencies in the 5 GHz band, at least for the US countrycode and the APs I've tested with, using the existing firmware blobs that OpenWRT currently uses.
Hello
Is there a way to make it working with LUCI in current snapshot? I have tried but despite the fact the phy report AC mode (before it said client or nothing) the AP WiFi is not working