Issue with DFS channels, fallback and warnings

When configuring 5 GHz radios on DFS channels with 160 MHz width (e.g., Channel 100 @ 160 MHz) on my AP6 Pros, the access points often fails silently — no SSIDs are broadcast, and clients cannot connect. 2.4 GHz remains functioning. However, the UI and CLI still report that the channel and width are active for 5GHz, misleading the user into thinking the radio is functioning. One cue here is that after a reboot the WiFi icon stays red, indicating 100 % load, from where it can be changed to Ch 32 @ 160, which works, and then tricked back to Ch 100 @ 160, which however fails silently. Ch 100 @ 80 MHz works as intended. DFS Ch 100-128 and 132-144 are allowed in this region, EU.

Commands like dmesg | grep -i dfs returns no output, and logread is not available.

At failure the radio remains disabled silently. The UI still shows the configured channel, width, and SSID, presumably being active, but iw dev and tx_packets confirm the radio is idle.

Any comments or solutions?

Looks like 100 is allowed but only if it’s 20MHz wide. For 160MHz wide channels you’d have to jump to 114 as the lowest chronological DFS channel number. We could definitely improve reporting around this. I’ll create a ticket for the development team.

2 Likes

Currently it is working again when set to either end of the block, i e. Ch 100 or 128 @ 160 MHz. So, it doesn’t have to be 20 MHz bandwidth when channels set at the respective end of the 100-128 block. And, previously, when silently failing at Ch 100 @ 160 MHz bandwidth it still worked with Ch 100 @ 80 MHz.

@Alta-Matt_v2, I appreciate that.