Read on SmallNetBuilder
SmallNetBuilder's Wi-Fi Dynamic Frequency Selection (DFS) FAQ
- Thread starter thiggins
- Start date
Read on SmallNetBuilder
sfx2000
Part of the Furniture
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...
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...
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 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?
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 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.
sfx2000
Part of the Furniture
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...
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=0sfx2000
Part of the Furniture
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:
sfx2000
Part of the Furniture
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...
The spec says all connections must be dropped, i.e. no further packets sent on the channel when the channel is vacated.
Similar threads
