What's new

SmallNetBuilder's Wi-Fi Dynamic Frequency Selection (DFS) FAQ

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

thiggins

Mr. Easy
Staff member
dfs_faq_teaser.jpg
What is Dynamic Frequency Selection (DFS) and why should you care? Here's the straight poop.

Read on SmallNetBuilder
 
Nice article...

Note that many clients _may_ support DFS, but scanner apps that use 802.11 Probe Request Messages for AP discovery may fail to see AP's in the DFS space...

Many will do a passive scan first - listening to see if there is already an AP present - the assumption here is that the AP has already tested and passed the radar detection...

I'm wondering if there should be a notation somewhere where Regulatory Domain is really important - and that 3rd Party Firmware that negates the DFS checks (or channels that are not legit in that Regulatory Domain) and transmit levels should be avoided - as this is a common question - esp in certain sub-forums...
 
There may be routers that support DFS but less clients do especially other devices besides PCs.
 
I look forward to all your articles Tim. Great article, you explained that all really well. Thanks!
 
Nice article!
I like to add some specifics:
The channels 120, 124 and 128 are specials, in all or most regions they require longer times for verifying. Many routers (including Asus at least in Europe seems to like to keep uniform timing schemes and simply skip those channels).
In case of wireless 5 GHz issues I first recommend to manual select one of the non DFS channels to avoid the verification process and potential radar conflicts.
 
I have a question about DFS, and if anyone can answer it I'd appreciate it greatly.

In my are there are dozens of 2.4 access points, but only 3 others on 5ghz (all on 80mhz, all on channels 36-48). I have an ac86u with 5ghz set to auto including dfs, it boots to channels 100-112. Now live a few miles from a heliport meaning several times a day a chopper passes over my home. Each time this happens the router, correctly, detects radar and changes the channel. However it does this by dropiing down a few channels each time. The net result is by the end of a day all 4 access points are operating on 36-48.The exact same process occurs if channels are selected manually (although the gui does not update when channels jump).

This effectively means the only available channels are 36-48. If I lived near a radar station this would make sense, but in European cities aircraft passing over is pretty common. Overtime time this will mean the most densely populated areas with the most access points will be on the same channels. Surly this cannot be by design?

I guess what I don't understand is why, once the non occupancy period is over, the router don't revert to dfs channels again i.e. spread themselves out across the spectrum. Is this deliberate or just Asus design?
 
I guess what I don't understand is why, once the non occupancy period is over, the router don't revert to dfs channels again i.e. spread themselves out across the spectrum. Is this deliberate or just Asus design?
I believe this is a design choice by ASUS. As long as the 60 second channel availability check is done and the channel is found clear, DFS channels can be reused.
 
I believe this is a design choice by ASUS. As long as the 60 second channel availability check is done and the channel is found clear, DFS channels can be reused.

Yep - most of the DFS logic is in the chipset itself and configured at run-time by the OEM driver..

The spec defines behavior, but it does not define implementation - this is left to the vendors and chipsets.

Broadcom and QC-Atheros are pretty good, Quantenna can be very good if not overly aggressive - can't speak for recent Marvell chipsets... I don't have firsthand experience with Realtek/Mediatek in 5GHz here...
 
Yep - most of the DFS logic is in the chipset itself and configured at run-time by the OEM driver..

A lot is configured through the acsd daemon (which is responsible for handling channel selection). I see quite a few nvram values (which might be hardcoded by the CFE tho, and not be user-editable). A few that caught my eye:

Code:
admin@Stargate88:/tmp/home/root# nvram show | grep acs | grep wl1 | grep dfs
size: 65119 bytes (65953 left)
wl1_acs_dfsr_activity=30 10240
wl1_acs_bgdfs_ahead=1
wl1_acs_bgdfs_idle_frames_thld=36000
wl1_acs_bgdfs_enab=1
wl1_acs_dfsr_immediate=300 3
wl1_acs_dfsr_deferred=604800 5
wl1_acs_bgdfs_idle_interval=3600
wl1_acs_bgdfs_avoid_on_far_sta=1
wl1_acs_dfs=0
 
A lot is configured through the acsd daemon (which is responsible for handling channel selection). I see quite a few nvram values (which might be hardcoded by the CFE tho, and not be user-editable). A few that caught my eye:

That would make sense - acsd is grabbing the desired settings from the WebGUI, and then passing them in the right format to the sta driver... similar to how this is handled by cfg80211 in the linux wireless stack that desktop linux uses.

Some params are also hard coded these days in the chip itself via OTP (One Time Programmable) memory writes poked in by the factory at the same time the MAC addresses are written into the WiFi chips.

Same thing happens on the client side devices (see the PCE-AC68 threads where some cards cannot see certain channels as they are not correct for the regulatory domain, and the only option is to buy the right card for the region)

Good place to look into some of the items that may not be fully documented in the GPL drop would be in the linux wireless docs/code over here...

https://wireless.wiki.kernel.org/en/users/drivers/brcm80211

It's not totally inclusive, and there's also the Broadcom STA driver docs that are a bit older...

https://github.com/poliva/broadcom-sta/tree/master/broadcom-sta-5.100.82.112

What's nice is now that Broadcom has sold off part of their WiFi portfolio to Cypress - the tech documents are much easier to get...

for brcmfmac, they're all pretty similar in design, so looking at docs like this are pretty useful for getting into the designer's head as to how/why they made certain decisions...

http://www.cypress.com/file/298076/download
 
Last edited:
There may be routers that support DFS but less clients do especially other devices besides PCs.

Many vendors disable DFS as it's a shed-load of testing with the DFS channels, it's not a simple thing, and the tests there are long and complicated... that's the technical answer

Most folks don't need DFS availability.. that the user answer

DFS is mostly wrapped around 5GHz, and this is the physics answer - for the most part, 5G works well enough within range...

Since we do not have harmonized bands/channels - it's a business decision for vendors that do global business...
 
I've got a Portal which seems to work really well in my apartment, despite there being at least 13 other wifi networks around me. It typically stays on channel 52.
 
Hello. When router detects a radar signal and changes channel, does it cut i tenet connection to wifi clients at that moment? Or will it cause lag spikes?
 
Hello. When router detects a radar signal and changes channel, does it cut i tenet connection to wifi clients at that moment? Or will it cause lag spikes?
The spec says all connections must be dropped, i.e. no further packets sent on the channel when the channel is vacated.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top