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)
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.
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.
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.