"Wireless not associated" on Wifi 5G when choosing channels 52 and up

OpenWrt: 23.05.0
Wifi5 SoC: Qualcomm Atheros QCA9880

When choosing channels 52 and above for the 5G radio on my OpenWrt, I get "Wireless not associated" status as shown in the pic below, and the 5G Wifis aren't visible on client devices. Then after about 5 min they get associated, they appear and everything works as expected. This is also the behavior after restarting the 5G radio or restarting OpenWrt.
Is this a bug or what is the cause for this problem on channels above 52?!

Worth to mention that changing the "country code" for both the 2.4G and 5G radios causes the a similar delay for certain countries, albeit not as long, maybe 4-5 seconds or so.

You must specify correct local country code, and same for both radios. It will take couple of minutes to select channel if there are any DFS channels present. Usually there is just one "clean" country change per device poweron, for subsequent changes restrictions just accumulate.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like

In most countries these channels have to give way to any radar system that may be present. The startup time is the time it spends receiving to check if a radar signal is present. If no radar is found, the AP starts up.

1 Like

The country thing was just a remark, the issue has no relation to that, it happens not matter what country I choose, and I'm choosing the correct country although that should not make a difference.

WIreless and ubus for now:

ubus call system board:

root@OpenWrt:~# ubus call system board
{
        "kernel": "5.15.134",
        "hostname": "OpenWrt",
        "system": "Qualcomm Atheros QCA9558 ver 1 rev 0",
        "model": "TP-Link RE350K v1",
        "board_name": "tplink,re350k-v1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.0",
                "revision": "r23497-6637af95aa",
                "target": "ath79/generic",
                "description": "OpenWrt 23.05.0 r23497-6637af95aa"
        }
}




cat /etc/config/wireless:

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:00.0'
        option band '5g'
        option htmode 'VHT40'
        option cell_density '0'
        option channel '52'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/ahb/18100000.wmac'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
        option channel '7'

config wifi-iface 'wifinet2'
        option device 'radio1'
        option mode 'ap'
        option ssid 'Binge'
        option encryption 'sae-mixed'
        option key 'eeeee'
        option network 'Binge'

config wifi-iface 'wifinet1'
        option device 'radio0'
        option mode 'ap'
        option ssid 'Jina'
        option encryption 'sae-mixed'
        option key 'fffff'
        option network 'lan'

config wifi-iface 'wifinet3'
        option device 'radio0'
        option mode 'ap'
        option ssid 'Jina_5G'
        option encryption 'sae-mixed'
        option key 'ggggg'
        option network 'lan'

config wifi-iface 'wifinet4'
        option device 'radio1'
        option mode 'ap'
        option ssid 'Jina'
        option encryption 'sae-mixed'
        option key 'hhhhh'
        option network 'lan'

config wifi-iface 'wifinet5'
        option device 'radio1'
        option mode 'ap'
        option ssid 'Work'
        option encryption 'sae-mixed'
        option key 'iiiii'
        option network 'Work_lan'

This will appear in the log:

Sat Sep 14 11:44:54 2024 daemon.notice hostapd: phy1-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Sat Sep 14 11:44:54 2024 daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->DFS
Sat Sep 14 11:44:54 2024 daemon.notice hostapd: phy1-ap0: DFS-CAC-START freq=5260 chan=52 sec_chan=0, width=0, seg0=0, seg1=0, cac_time=60s
Sat Sep 14 11:44:54 2024 daemon.notice netifd: Wireless device 'radio5' is now up
... (exactly 1 minute later)
Sat Sep 14 11:45:58 2024 daemon.notice hostapd: phy1-ap0: DFS-CAC-COMPLETED success=1 freq=5260 ht_enabled=1 chan_offset=0 chan_width=1 cf1=5260 cf2=0
Sat Sep 14 11:45:58 2024 kern.info kernel: [  694.287029] IPv6: ADDRCONF(NETDEV_CHANGE): phy1-ap0: link becomes ready
Sat Sep 14 11:45:58 2024 kern.info kernel: [  694.294135] br-lan: port 2(phy1-ap0) entered blocking state
Sat Sep 14 11:45:58 2024 kern.info kernel: [  694.299837] br-lan: port 2(phy1-ap0) entered forwarding state
Sat Sep 14 11:45:58 2024 daemon.notice netifd: Network device 'phy1-ap0' link is up
Sat Sep 14 11:45:58 2024 daemon.notice hostapd: phy1-ap0: interface state DFS->ENABLED
Sat Sep 14 11:45:58 2024 daemon.notice hostapd: phy1-ap0: AP-ENABLED

I think that CAC stands for Channel Availability Check, i.e. confirm there is no radar.

1 Like

It does make a difference - only choose your correct country code.

This is legal, normal and expected behavior for these channels on 5.4 GHz WiFi. There is no bug.

1 Like

Thank you for the informing response, after doing some reading it is exactly what you all guys said. My ignorance.

Thank you for the informing response, after doing some reading it is exactly what you all said. My ignorance.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.