UPDATE: See the comment below by Andrew Von Nagy. It clarifies what I said about hidden SSIDs and DFS.
I'm a huge advocate of using DFS channels in most medium to large deployment scenarios. But, you should always validate your channel plan and make sure it doesn't cause issues with you WLAN. By that I mean verify that your devices actually do support DFS. It’s possible certain devices support DFS, but not ALL DFS channels. Checking manufacturer documentation, Google, or site like clients.mikealbano.com can help you figure that out.
Case in point: Hidden SSIDs. Most wireless folks recommend against using hidden SSIDs. It doesn't provide any security, requires more work to connect devices to, and some NIC drivers don't like hidden networks and won't, or have trouble, connecting to them.
There are practical reasons to hide an SSID - to avoid confusion between networks, or to simplify your network advertisement. But, security isn't one of them, the AP is still beaconing, clients probe more (so you're wasting airtime and announcing the SSID anyways), and the SSID is sent in plaintext in association requests anyway, so it's not that difficult to find them.
But, there's yet another reason to avoid hidden SSIDs - especially if you want to take advantage of DFS (Dynamic Frequency Selection) in your WLAN:
I'll admit to doing "little contemplation" on this. Fortunately, I don't run into hidden networks that much these days (thank goodness), but I've also spent little time considering the consequences of DFS and hidden networks. Using hidden networks on DFS channels can cause unforeseen connectivity issues.
Clients can't actively probe on DFS channels. Active Probing is when a client send a "Probe Request". Clients send probes on a channel to discover any potential APs. Since ACTIVE probing is not allowed on DFS channels, clients will do Passive Probes - which simply means they listen for beacons on a channel. Well, if they just happen to listen BETWEEN beacons, they’ll miss what they don’t see.
This also has implications for voice and roaming. If the clients can't probe for new APs then roaming times will be longer, and real-time data starts having issues. Many hospital deployments don't use DFS because of these issues.
Just food for thought. If you need frequency re-use (and these days who doesn't?) you'll need DFS. And DFS does not play well with hidden SSIDs. So, just stop hiding your SSIDs. Another thing you can do is mix your channel plan up so you don't have all DFS in an area. Always have non-DFS channel options available in case the device doesn’t have enough time to find the channel, or it doesn’t support it.
One final note, if roaming is important, you should be using 802.11r and devices that support it. And in conjunction with 11r use 11k/v to help speed up channel discovery. Of course, make sure your infrastructure and your devices support these features, and test them thoroughly to insure there are no compatibly issues when enabling them.
UPDATE: See the comment below by Andrew Von Nagy. It clarification hidden SSIDs and DFS.
Actually, that isn't correct. Clients can't initiate transmissions on DFS channels, which prohibits most of the benefits of probing... namely faster discovery of the APs operating on the channel. But hidden SSIDs have no impact on this. Once a client hears a beacon on the channel by a "master" device (that must conform to radar scanning regulations) then it is safe for a client to probe.
So the real issue is two fold with DFS and client scanning:
1) Longer initial AP discovery time due to waiting until it hears a beacon (102.4ms intervals) instead of probing immediately (discover within just one or a few ms), and
2) Longer scanning time when roaming, especially for latency sensitive applications such as voice.
Whether or not the beacon populates the SSID IE field is irrelevant.
Cheers,
Andrew