“Wireless isn’t working!” – everyone

How many times have we heard that mantra? As wireless engineers we know all of the intricate details that are required to be in place before wireless “just works.” We often find ourselves trying to explain this to people who see wireless as magic, and us as the magicians. They don’t care about the intricacies of roaming. They don’t care about the underlying systems, many of which we rarely control. DHCP, DNS, RADIUS, and ultimately the services they are trying to connect to.

Assuming a medium to large sized corporate environment, there is likely someone (a team) responsible for the DNS, DHCP, and Radius, and that is not likely to be the same team responsible for wireless. In very large environments, the LAN team that even provides the network cable for the AP may be a different team.

Further increasing the confusion is that problems can often appear isolated, with only a small group of users experiencing the issue.

Then the troubleshooting must begin. Is it a client issue? Were drivers or firmware recently updated on the users systems? Is there a common location, time, or AP that the experience is related to? The list of questions begin to build.

I ran into this in my own network recently. Users were complaining of being unable to connect to wireless. The problems were reported from various locations slowly over a number of days. No particular client was having consistent issues, and I never saw the problem on a customers computer while they were having it. I began looking through logs and following pretty standard troubleshooting steps. Nothing came up. It was as if the problem didn’t exist, yet I was hearing about it often enough to believe that it did.

Considering that I had just returned from Mobility Field Day 2 and participated in the Cape Networks session, I had an idea. Cape Networks provided delegates with a sensor to test. I spoke with my manager at work, a very smart guy (he hired me, right?) who agreed it would be OK to test the sensor in our environment.

The secret to the Cape Networks sensor is that it IS a client. It sees what a client experiences and its entire function is to report on the user experience. It is cloud connected, with an intuitive dashboard, that makes setup and management easy, and remote troubleshooting painless. You really should watch the Cape Networks presentation!

After installing the sensor and configuring the device for our wireless network and the internal services that I wanted it to test, I walked away and forgot about it for a day.
The next morning, I logged back in, and my issue was staring me in the face. DHCP

The time to get a DHCP address was all over the map, peaking as high as 11 seconds. Problem found! Users who experienced those peaks would clearly have issues connecting; add in their own impatience, maybe turning off and on wireless, and of course they couldn’t connect.

Before and after changes were made to DHCP.

What was even more important was that I now had clear metrics that I could take to my team that manages DHCP. I could point to the problem, and then after we developed and implemented a resolution, I was able to point to the same metrics as proof that our plan worked.

As you might have guessed, complaints and rumors of complaints quickly died away.

My organization has since made the decision to invest in sensors from Cape Networks. Their reporting and ease of use make for an unmistakable value. I strongly recommend that you also check them out.

As a MFD2 delegate, I did receive a free sensor from Cape Networks and various stickers and other low value (but tasty) snacks. All other expenses for MFD were covered by Tech Field Day. I was not compelled to write about Cape Networks in any way other than personal user experience. My employers decision to purchase sensors was based solely on the user experience and ease of problem resolution.