THE BLOG ★ Ramblings on WiFi & stuff.

DFS implications for hidden networks and roaming

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

♻︎ Today’s Quality Linkage

What is Your Wireless Engineering Worth? About doing things right.

Clarifying Wi-Fi Terminology webinar from iBwave featuring CWNE Alan Blake (@papageordy).

Co-Channel Interference (CCI), in the real world discussion at WirelessGeek.net on CCI and when it matters.

802.11 MAC Series – Basics of MAC Architecture – Part 2 of 3 from CWNP

802.11ax Proposed Enhancements for those interested in what's ahead.

Radio Frequency For Wi-Fi Administrators a Udemy course by GT Hill

Gravitational waves exist: the inside story of how scientists finally found them I love science!

Gravitational Waves Comic and Animation Even I can understand this!

This iOS date trick will brick any device [Video] Imagine someone spoofing an NTP server. 😱

The science behind OK Go’s latest jaw-dropping video Yeah, ♥ these guys!

SCIENCE! Gravity Waves are real. Guess that Einstein kid was right after all.

 from New Scientist:

Since gravitational waves were predicted by general relativity, they offer a chance to verify that Einstein’s theory really is the correct account of gravity. So far, general relativity is passing with flying colours: the observed signal is perfectly explained by Einstein’s equations.
But the real excitement is that gravitational waves can show us a side of the night sky we’ve never seen before. Until now, there had been no sign of black holes in this size range – much less two of them.

 

Science is cool. 

and from Scientific American: 

The discovery is not just proof of gravitational waves, but the strongest confirmation yet for the existence of black holes. “We think black holes exist out there. We have very strong evidence they do but we don’t have direct evidence,” Lehner says. “Everything is indirect. Given that black holes themselves cannot give any signal other than gravitational waves, this is the most direct way to prove that a black hole exists.”

 

Yeah, nerds, Black Holes are real! (Probably)

 

♻︎ Today’s Quality Linkage

When is a wireless issue a "wireless" issue?

Estimated reading time: 3 minutes, 10 seconds. Contains 635 words

 

If you're into wireless and aren't following Lee Badman's (@WiredNot) #WIFIQ (Wi-Fi Question of the Day) hashtag on Twitter, then I'll just wait while you go ahead and do so.

It's o.k. I'll wait.

Ready? Good.

I really like this question, because it does emphasize one fact about WLANs - it's more than just the wireless. There are other very important things you need to have a well performing WLAN. The question asks what issues do you typically run into when troubleshooting wireless networks that ARE NOT necessarily wireless issues. The answers were varied and insightful as they are for all the #WIFIQs.

There are many "wireless", or 802.11 based specifics that can affect wireless performance. A short list would be:
 

  • Client can't associate to an SSID because a particular feature (like 802.11r/k/v) is enabled and the client driver does not like that - so it refuses to connect.
     
  • Clients can't connect because you have WPA2 enabled, but not WPA (the older client only support TKIP).
     
  • You expect a certain connection speed, but the WLAN is configured for 20MHz channels, instead of 40, or 80.
     
  • Clients are having connectivity and throughput issues because channel reuse is poor (maybe you're using 80MHz channels) and co-channel interference is exacerbated.


These things are clearly 802.11 related and can rightly be considered "wireless" issues. But, what about the guest user that is connected to the WLAN, but can't get an IP address? Or, the client that connects to guest network and never gets the promised captive portal? These client have associated to the AP, but are unable to get network access. And of course: user complains that they enter their credentials, and they just can't connect. Are these wireless problems?

I can think of several reasons why the above mentioned clients could be having these issues, and none of them are "wireless". For example, the IP address issue could simply be a depleted subnet. Many guest networks use long lease times (read: default) and don't realize a client connected several days ago could still have an address reservation that has not expired. Even with a small number of clients you could exhaust the address pool in a few days, or weeks.

Or maybe to was incorrectly configured switch ports. If that AP is placing client in specific VLANs, and those VLANs are not tagged on the port, that would also cause our "no DHCP" issue.

The captive portal could be several things: no DNS properly configured, no IP on the guest VLAN interface, the old "DHCP exhaustion" issue, etc. These are all technically not wireless issues, but can absolutely affect, and be detrimental to your wireless clients.

And the password/credential issue? The most obvious one is they forgot, or incorrectly entered the password, or login credentials. Another possibility is their account was deleted, locked, or de-actiavted, so RADIUS authentication is failing. OR, someone fat-fingered the RADIUS shared secret when setting up the server, and RADIUS is ignoring the request.

So, the moral of this lil' ditty is that you need to be aware that there is more to your wireless network than wireless. You need to understand DHCP, addressing schemes, PoE, cable types, firewall rules, RADIUS servers, etc. You may not have responsibility, or access to do anything about them, but you should be able to diagnose, and troubleshoot these issues and get folks involved that can help.

Regardless, when someone says, "the Wi-Fi don't work!", and it's not a "wireless" issue - it doesn't matter. The user doesn't know, or care, they just want it fixed. Being able to quickly determine where the issue is originating will go a long way in making your users happy.

As my buddy Jake pointed out:

♻︎ Today’s Quality Linkage (Friday, Feb 5, 2016)

Hotspot 2.0 in the wild →

So, it seems public Wi-Fi may finally be coming of age big time. LinkNYCs blog has a write up of their "Secure" public WiFi:

 via Medium:

LinkNYC has two free Wi-Fi networks, ‘LinkNYC Free Wi-Fi’ and ‘LinkNYC Private.’...
 
The ‘LinkNYC Private’ network goes a step further, offering state-of-the-art encryption via HotSpot 2.0 and WPA to secure all wireless communications between devices and the Link, regardless of whether a website uses SSL security. This means that even casual browsing is protected from snooping. The network is one of the first in the country to offer an encrypted public network at this scale.

 

Hotspot 2.0, or 802.11u, OR "Wi-Fi Certified Passpoint" (Blerg.) is an amendment that specifies internetowrking between external networks. Per the amendment:
 

support for external authentication, authorization and accounting, together with network selection, encryption, policy enforcement and resource management.


At launch it will only support Apple mobile devices (of course), but will add other device support over time.

Hotspot 2.0 has been a thing for a while, and this is not the first network to provide it, but with all the attention this project is getting, I have the feeling Hotspot 2.0 may actually have it's day - like legit.

But, there's more! Fierce Wireless is reporting "AT&T in process of upgrading Wi-Fi in NYC parks with Passpoint". "Passpoint" is the Wi-Fi Alliance's marketed name for Hotspot 2.0. That's pretty huge. Two major wireless initiatives in the largest city in the U.S. rolling out secure public wireless.

For those unfamiliar with Hotspot 2.0 I refer you to this blog post by Ruckus Wireless' Dave Wright.

♻︎ Today’s Quality Linkage

RRM Design – Putting it into Perspective A reasonable viewpoint from Alan Blake.

Yeah, where the frak IS Waldo?! Yes, it's about wireless.

Wireless NICs, External USB Hubs, and Noise

Oldie, but goodie: When 802.1X/PEAP/EAP-TTLS Is Worse Than No Wireless Security

And, another one... How secure is your EAP-PEAPv0 deployment?

China Just Released True Color HD Photos Of The Moon Commies on the moon! What's not love!

WALLPAPER WEDNESDAY! The SR-71 Blackbird is just so friggin’ dope!!!! Here’s a pic. And here's another. And another.

Survey For Your WiFi Clients Knowing how your CLIENTS see the WLAN is better than how your NIC sees it.

What Anyone in Wi-Fi Needs to Know About Ethernet

Her Code Got Humans on the Moon—And Invented Software Itself Girls rule!
 

via @BLAKEKRONE: Where's Waldo? (or, The case of the missing wireless engineer.) →

Blake Krone, via his blog →

What do I mean by a skilled wireless engineer? Do I mean they are CWNE or CCIE or AC[]X? No, not at all. I simply mean someone that understands wireless and the challenges it brings when trying to design. It’s the person that knows about Co-Channel Interference and Adjacent Channel Interference, someone that understands when and how to use 20/40/80MHz channel widths, the person that knows you have to do a survey to get things right, etc.

I think sometimes we (myself included), as wireless engineers, make it seem impossible for people to think they can unlock the "secrets of Wi-Fi". No doubt there are some complicated things, but no more so than some other enterprise technologies out there as Blake points out. He thinks it's the PERCEPTION of wireless be too high an entry level and I tend to agree.

Maybe we need to preach some more "bare bones" wireless for the network folks out there that don't have the budget, or support, to access the expensive tools we all desire. Things like knowing WHAT to look for when doing a wireless scan, or basic understanding of channel management could go a long way to helping the many over-burdened IT individuals out there saddled with the task to install a WLAN. At the very least enough knowledge to know when to call in an "expert". In the end what we really need is to bring more people into the wireless fold.

♻︎ Today’s Quality Linkage