Channel 13 & 12 & Auto not functional on raspberry pi 3B / zero w

Are channels other than 1-11 purposefully disabled in stable OpenWrt 19.07.05?

I've been trying to get raspberry pi 3B / zero w running OpenWrt as AP to use Channel 13 & 12. The channels are perfectly legal in most of Europe and Poland. Selecting them disables the wifi completely.

Going over the messages, there is something wrong with the country selection (hostapd messages) OR the choice of channel by the driver (nl80211/ieee80211):


Wed Dec 30 04:16:42 2020 daemon.err hostapd: Failed to set beacon parameters
Wed Dec 30 04:16:42 2020 daemon.warn hostapd: wlan0: Could not connect to kernel driver
Wed Dec 30 04:16:42 2020 daemon.err hostapd: Interface initialization failed
Wed Dec 30 04:16:42 2020 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->DISABLED
Wed Dec 30 04:16:42 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Wed Dec 30 04:16:42 2020 daemon.err hostapd: wlan0: Unable to setup interface.
Wed Dec 30 04:16:42 2020 daemon.notice hostapd: wlan0: interface state DISABLED->DISABLED
Wed Dec 30 04:16:42 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Wed Dec 30 04:16:42 2020 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Wed Dec 30 04:16:42 2020 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Wed Dec 30 04:16:42 2020 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Wed Dec 30 04:16:42 2020 kern.err kernel: [ 8810.195905] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=4109, -52
Wed Dec 30 04:16:43 2020 daemon.notice hostapd: ELOOP: remaining socket: sock=22 eloop_data=0x7fb0bb4e60 user_data=0 handler=0x41d078
Wed Dec 30 04:16:43 2020 daemon.notice netifd: radio0 (8612): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process 8118 path ()
Wed Dec 30 04:16:43 2020 daemon.notice netifd: radio0 (8612): Device setup failed: HOSTAPD_START_FAILED

Selecting auto indicates a driver scan problem, followed by hostapd failing to recognise automatic channel selection:

Wed Dec 30 04:16:49 2020 daemon.notice hostapd: ACS: Automatic channel selection started, this may take a bit
Wed Dec 30 04:16:49 2020 kern.info kernel: [ 8817.154489] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Wed Dec 30 04:16:49 2020 kern.err kernel: [ 8817.166683] ieee80211 phy0: brcmf_run_escan: error (-52)
Wed Dec 30 04:16:49 2020 kern.err kernel: [ 8817.173057] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-52)
Wed Dec 30 04:16:49 2020 kern.err kernel: [ 8817.184908] ieee80211 phy0: brcmf_run_escan: error (-52)
Wed Dec 30 04:16:49 2020 kern.err kernel: [ 8817.191232] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-52)
Wed Dec 30 04:16:49 2020 daemon.err hostapd: ACS: Failed to request initial scan
Wed Dec 30 04:16:49 2020 daemon.warn hostapd: wlan0: IEEE 802.11 Configured channel (0) not found from the channel list of current mode (1) IEEE 802.11g
Wed Dec 30 04:16:49 2020 daemon.warn hostapd: wlan0: IEEE 802.11 Hardware does not support configured channel
Wed Dec 30 04:16:49 2020 daemon.err hostapd: Could not select hw_mode and channel. (-3)

Has it ever run the official Pi OS? Reportedly you need to run PiOs once and set the country code, it will write that permanently into the radio chip. Then it should work properly for that country under OpenWrt.

The CRDA that had been in use with the rpis when these were running raspbian would still be in the firmware if the theory were true.

On raspbian, rpis were in use as clients and fine with connecting in station mode to an AP on all channels, including channels 12 & 13.

Here's recent proof from a rpi3b in client mode:

$ iw wlan0 info
Interface wlan0
        ifindex 2
        wdev 0x1
        addr <redacted>
        ssid <redacted>
        type managed
        wiphy 0
        channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
        txpower 31.00 dBm

The firmware based CRDA theory is false hearsay. No official sources state anything about CRDA being committed to the hardware permanently.

All that raspi-config tool appears to be doing is setting the CRDA in wpa_supplicant.conf and issuing 'iw reg set '. Mind raspbian uses the setting for the client mode, not AP. I haven't tried AP mode for raspian.

It sounds like nonsense but I gave it a go: booted to raspbian, connected in station mode to an AP forced to channel 13. After booting to Openwrt, predictably channel 13 does not become magically available.

There is some improvement with openwrt snapshot. Auto channel selection is possible in client mode. Channels 12 & 13 still fail both in AP and client mode.
A sample failure message reads:

ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=4109, -52