AP dies out with DFS-RADAR-DETECTED message when both 2.4GHz and 5GHz AP defined

I'm having some issue when running master (r14660-5423d9d27e). I have 2 Luma devices upgraded to OpenWRT, both running the same build.
The 1st device is running on my main floor and has 2 APs configured: 1 on the 2.4GHZ for g/n protocols and 1 on the 5GHz for ac protocol.
The 2nd device is running on my top floor and has only 1 AP configured on 5GHz w/ ac protocol.
Both devices have the exact same settings for the 5GHz APs (using channel 108) so that I can easily roam between them.
The problem is that the 5GHz/ac AP on the 1st device dies out frequently (several times a day). I can see a DFS-RADAR-DETECTED message in the system logs right before it dies.
But I don't see that same DFS-RADAR-DETECTED message on my 2nd device (where only the 5GHz AP is configured), so I think it's a false positive (I actually used to have the same problem on the 2nd device when it too had a 2.4GHz AP configured, but the problem went away when I decided to remove that AP).
The behavior seems similar to what others have reported. see 5 GHz WLAN craps out (upon radar detection?) - start_dfs_cac() failed.

How can I confirm it is indeed an incorrect DFS-RADAR-DETECTED signal that is crashing my AP?
Any recommendation on how to fix it or work around it? (I do need at least 1 2.4GHz AP)

thank you!

You can't (without extremely expensive equipment and NDA level access to driver/ firmware sources and hardware documentation), if the driver thinks it sees a DFS event (there may be false positives, reducing these to acceptable limits -while at no point allowing false negatives- is a major topic/ effort for the driver/ firmware developers), it must vacate the affected channels immediately - that's expected/ required behaviour and not a bug. The only thing you can do, is trying to avoid the affected channels (ideally to non-DFS channels, maybe other DFS channels far away might also do).

Yes, there are significant differences in the DFS detection qualities of different hardware/ drivers in regards to the amount of false-positives seen in the wild, but there isn't anything you can do as a user (the DFS algorithm is part of the FCC/ ETSI/ MKK/ … certification), without firmware source access and lab equipment in the 6+ figure range.

Can you try lower 5GHz channels like 36, 44?

I use 5GHz DFS channels and no problem with

For master Access Point:
Channel -> Auto
Country -> 250 ( Country FR )

I have 3 others WIFI Box in Client ( relay )

At this time channel is 120

Thank you for the detailed, informative answer. I guess I was hoping it would be a simple issue to fix b/c the problem only occurs if I have 2 APs defined. But I understand that if it's in the firmware that may not be feasible.
I've changed to a channel outside of the DFS range. Will reply back if I still get issues, but for now, it seems to be stable.

thanks again.

I'd assume that the more affected device is just closer to the wall/ sees the DFS events easier - or is closer to an interference emitter that gets (mis-)interpreted as DFS event. It's quite likely that the error would move, if you'd let both devices swap their location.

and yes, DFS parsing is done on firmware for ath10k.

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