Introduction
While there is the IEEE Standard 802.11 that defines the Wireless LAN technology, there are some settings (let’s call them tweaks) the AP-Manufacturers let you implement that are supported by the vast majority of the client devices, but are not part of the 802.11 Standard itself.
Arguably two of the most popular ones amongst them are:
– Hidden SSID
– Don’t Answer Broadcast Probes
I myself was fond of these settings for a long time, but had to reconsider them after I stumbled across a problem a couple of months ago.
Hidden SSID
Hiding your SSID will remove (null) the SSID Element in the Beacon Frames and Probe Response Frames.
Despite the fact that (on first glance) this looks like a good way to secure your WiFi, it should NOT be considered a security feature: Every person that is a little technophile is able to get his/her hands on your SSID, even if you hide it, because an SSID cannot be removed from Association Request and Reassociation Request Frames.
But hiding the SSID can still be considered a handy feature: if you have a guest WiFi and an internal WiFi, you can prevent guests from accidentally trying to access the internal WiFi by hiding it, and therefore protect your helpdesk from unnecessary phonecalls.
Don’t Answer Broadcast Probes
As an addition of listening to Beacon Frames (Passive Scanning), a client can send out Probe Request Frames (Active Scanning) to get an overview of the available Wireless LANs in earshot.
Beside the possibility to send a Direct Probe Request to one of its known SSIDs (“Hey “HomeSSID”, are you there?”), there is the option to send Broadcast Probe Requests, where no SSID is specified (“Hey, is somebody here”), upon which every WiFi that hears this request has to answer with a Probe Response Frame.
Because in our case, every client that was allowed to connect to the internal WiFi got the internal WLAN profile manually configured and therefore “knew” its SSID, we decided that the internal SSID should not answer to Broadcast Probe Requests to reduce the amount of unnecessary Management Frames.
How These Settings Can Impact Roaming
Roaming is such a big topic itself that it deserves its own book, so I am not going to open this whole can in this blogpost.
Fact is, that the roaming decision is made by the client – normally when it hits a certain threshold (based on signal strength, SNR, error-rate, etc.). This threshold is different from manufacturer to manufacturer, from driver version to driver version, and they never disclose them, so there is only a guesstimation we can make to say at what point a client is going to roam.
When a client hits this custom threshold, it starts to look for new APs within the same ESS it can roam to – so besides only listening to the Beacon Frames, it starts to send out Probe Requests.
These Probe Requests are usually Direct Probe Request, because the client wants to connected to an AP within the same ESS, and not to a different or new SSID.
But I discovered a client that was new, but had a really cheap 802.11g NIC built in, and unfortunately sent out Broadcast Probe Requests when it wanted to start roaming.
The consequence of this behavior (in combination with the 2 settings described above) was, that the client desperately tried to find a new AP it could roam to, but never got an answer, and consequently stayed on its AP until it lost its connection. Ironically, after the disconnection, the client sent out a Direct Probe Request and was able to reconnect to the WiFi again.
But because the client was not able to properly roam and had to disconnect and reconnect every time, there was always a downtime of ~30-60 sec.
I hope this post is helpful for some of you out there facing a similiar problem.
Cheers, Renzo
