Sometimes, we can hear an important lesson many times, and while it registers…that doesn’t mean we won’t still overlook things. This is one of those stories, and I am sharing it because, well, it’s a good learning experience…and perhaps it will save someone else a bit of time, stress, pain or troubleshooting.
Any time we design a WiFi network, one thing we must ensure we do is gather requirements. One component of that process is understanding what devices will be on this new WiFi network, and what their capabilities are-and are not. Sometimes this will be simple enough-is the device only capable of utilizing the 2.4ghz network? Is it a newer device that can’t handle fast roaming? Is it a device incapable of supporting certain channels? All of these are important questions (and there are many others, I assure you) and they should be asked sooner rather than later.
For the purposes of this teachable moment, it’s devices and channels that are important.
I will admit right here, that I overlooked that certain devices I’d be supporting would have a channel issue. So, here’s how this came up…
I recently did a deployment in a large open space. The plan was a literal rip and replace, swapping the old APs with new ones, nothing else was moving nor being added to the site I spent a few days on site for tuning and surveys during the cutover, to make sure everything went well. My surveys in Ekahau looked solid, my own experiences walking around the space with numerous devices was fine. Customers had similar experiences.
Fast forward a couple weeks, and they have a particular type of device that is having issues. It didn’t seem to be having issues during my time on site, but it would seem we had too small a sample size.
The complaint? WiFi was weak in many spots and non-existent in others, but only for these scanners. Nothing else.
First thought was the device software needed to be updated-and, to be fair, when you introduce brand new access points with new radios, chances are devices can benefit from updates to function best on the new network. While that was explored, it was not the fix…but it did lead us to one.
Doing a screen share of the devices, the vendor showed me a screen that showed WiFi information. They were talking about forcing the devices to one band or another, and then said “Oh, why don’t we lock it to a specific channel?”
And then it began to come into focus…
Looking at that configuration screen, it was clear that the devices were steering clear of the entire UNII2 space. That is a lot of spectrum these devices can’t use, or at least, were configured to not use.
I compared those notes to my Prime heat map…and 90% of the APs covering the open area? Yep, they were using the channels that the devices could not. Which means? While the space was actually covered very well, to the scan guns, coverage was atrocious. Out of 21 installed APs, they could only talk to 5 or 6 devices-and 3 of them were separated by office walls.
Now, I did some digging, and unfortunately the decision to turn every one of those channels was made before most involved in this project were around. No one could confidently answer why the channels were disabled…but I made an educated guess.
The facility sits less than 2 miles away from the airport. In the flight path I am sure. No doubt, they either had DFS issues at one point, or were concerned about having them…so rather than chance it, they avoided the channels entirely.
So what was the fix? Well, to confirm that was truly the issue (and, I was pretty confident it was), we turned on the channels on a couple of the devices, to see if things improved. Once we verified that, and with an eye toward avoiding any possible future issues, we disabled the channels on the controller. Part of this was also because it was a lot easier for me to make the changes on the WLC, as opposed to having them manually change every scanner.
Because of the way the site is, and what they are doing, we knew we would be fine working with a reduced channel plan in 5ghz. Once the change was done, every device was able to be used everywhere it was needed to function, and as expected.
Lesson learned? If you have some non-standard (IE, not a typical smart phone/tablet/laptop) it is always worth validating what channels they can/cannot/are configured to use, and designing accordingly. Don’t want to have the bad luck of overlooking that step and then deploying a network that is using a lot of channels which your devices cannot.
In my case, this was more than likely a decision made years ago to avoid issues, because the devices were capable of supporting the entire 5ghz spectrum. Because it was working fine under the old config, and because there are no concerns about lack of channels to be used, this was a solution that I was comfortable with, and the customer was satisfied with (but yes, I know there are other ways to handle this scenario-always more than one way to skin the cat).