DFS Radar Detection even on non-DFS Channels?

I have recently Upgraded my Netgear R7800 to Kongs 11-29 build after already having issues with the 11-23 build concerning intermittent WiFi Loss for some Minutes on 5GHz. First i thought this was due to the 160Mhz Problem already documented, however, i recently found out my Problems are caused by DFS, which were no problem before at least the 11-23 release.

I then thought it would be a good idea to just set the AP to a specific Frequency (Channel 36), which would be DFS free up to channel 48 in my Country, so that would work with 80Mhz width.
However: I STILL GET RADAR WARNINGS ON CHANNEL 36: https://pastebin.com/pkJhtJYf
The other Problem seems to be that CSA scheduling sometimes fails, which disables the AP for 10 Minutes or so.

What can i do to mitigate this Issue? Should i flash a new official rc Build?

As you can see the centre frequency for 160Mhz is 5,250GHz or channel 50 and it overlaps with DFS channels.

I would have expected Problems with 160Mhz with, however, i am only using 80Mhz, which is totally fine as the lowest Frequency is channel 36 and highest is 48, so the center Frequency would be 5210, which is not DFS, even channel 48 (5240) is not DFS... or am i missing something here?

Then maybe the frequency has not actually changed?
Can you confirm it with a mobile scanning app?

Well it has, i can see that in the WebUI and in the scanning App, Sometimes the Channel Changes to 100, sometimes its 52 or some other Channel... unfortuantely i cannot prove it atm as i am not at home

Choose a country code that doesn't require DFS....

Radars are the primary, licensed, user of these frequencies. WiFi APs must vacate the affected channels immediately, if they detect radar pulses on DFS channels. The interference caused by a rogue AP can disturb radar signals over quite large ranges, visibly distorting the radar images over 60-80 km - meaning you will get noticed. The fines imposed by FCC/ ETSI/ MKK and other regional regulatory domain authorities can easily go into the 5 figure range (and above) and do include jail time for intentional/ repeated offenses.

Users willfully ignoring sensible regulatory restrictions are a huge reason for FCC/ ETSI becoming more heavy-handed while revising their regulatory requirements and laws, so anyone intentionally violating these is doing a disservice to the community at large.


Found the problem: The wireless-regdb Entries for the Country Code "CH" are totally screwed up in the version that OpenWRT ships. I will be filing a bug report, for everyone else: The Specifications for "CH" and "DE" are the same in the fixed version that is not yet available in OpenWRT. Just use "DE" on your 5GHz WiFi.

I think @Richto meant "Choose a country code that doesn't require DFS.... and move to that country".
I'm pretty sure he was not suggested any kind of illegal activity.


Noted. Was not aware of the details as to why so thanks.

I use only 80MHz chan widths on low 5Ghz chans so don't have any reason to worry about DFS myself, but i noticed that it doesn't seem to apply in India for instance, and that India also allows 24dB power output levels.

Is there a file in build repository for instance that shows all the settings so that people can check their country settings are correct?


This file is available in the build repository via package/firmware/wireless-regdb. Just do a make package/wireless-regdb/prepare and you'll be able to find the file db.txt in the build directory.

You can edit this file to alter the settings, which I've already done since the settings for the UK are hopelessly wrong.

It's important to report issues with wireless-regdb to the linux-wireless mailing list, also provide the source for the basis of your bug report.

1 Like

I'll leave that for a day when I have the time to craft an email with links to the different documents that need to be consulted to get the right settings :slight_smile:

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