Wi-Fi reviews are not the easiest of things. Unlike fault finding most networking, Wi-Fi has the added complexity of RF - and all those multitude of clients. In this blog, we'll take a measured run through on where to start in your fault finding journey.
The evidence gathered will be dependent on the type of review and the requirements for the specific review. There are certain general things which are required and these are detailed below.
Wi-Fi troubleshooting can take a lot of forms and deciding how to approach this will depend on the issues your facing.
One approach we take is to start with a comprehensive review of the existing network.
This is the second in a series to look at how to review a Wi-Fi Installation. See the first part on this series: How to Review a Wi-Fi Installation.
Wi-Fi troubleshooting is an extensive topic, and there's also a other blogs on our website might might be help - whether you're looking to fix warehouse, hotel or educational Wi-Fi, there's something to help.
ASSOCIATED BLOGS:
To start the approach to remediation, you need to baseline your network - work out what might be wrong and start there. You could dive straight in to the debug phase - but in my experience that's a slow way to get to the root cause - you'll be examining thousands of lines of debug.
So - if you don't start with the debug - where do you start?
The existing design document can be reviewed to determine if best practice has been used and it meets the required specification (for example what type of HA has been used, what code selected, how have the various VLANs been configured and so on).
All too commonly you'll find that multiple engineers have worked on an install - and they haven't cross checked what they've done with each other.. don't skip the basics - sometimes faults were designed in from the start, so always worth a check.
As a good bit of background, have a read of 30 Technical Wi-Fi Thoughts - good reading to set the scene for the fault finding.
Surveys are open to being incorrectly undertaken. We've seen a whole host of things not to do. Incorrectly configured survey files can show that you have a sea of green, giving the impression of full coverage - yet clients drop out. Reviewing how surveys have been undertaken and how they have produced incorrect results can be illuminating.
Gathering data onsite can take a number of forms. In the first instance, talking to users to hear their experiences can help to build a good picture on what's happening. Site surveys, spectrum analysis surveys and just walking around to see the building fabric provide useful information for a review
ASSOCIATED BLOGS:
A post install survey will provide data on how the network is performing, as well as data on interference, channel overlap and so on. Beware doing a survey when the APs are running high power - this really just gives you the illusion of good coverage. APs must be running an appropriate power level for the end devices in use - explained further in our blog titled Wi-Fi and the Cinema Story.
Don't forget the pre-install surveys too - pretty handy to have pre-tested a site prior to cabling, although if you're at the fault finding stage, it's a little too late for the pre-install survey.
ASSOCIATED BLOGS:
We run a service called an Assurance Review to undertake an in depth run through on the controller and provide advice on all the settings to change. This is really setting the controller to the best baseline options for the site in question.
The aim is to take a thorough look through the current controller configuration and fix a range of issues quickly.
ASSOCIATED BLOGS:
Debugging on the controller is a fundamental tool in working out any issues on a Wi-Fi network. This can extend to the client, where the client is capable of this too. We also use wired and wireless sniffs to complement the data gathering and these help inform us with the full picture.
ASSOCIATED BLOGS:
Since you can so easily just listen to a phone and hear Wi-Fi phone dropouts and other issues, it's very easy for end users to spot issues with these devices.
Coupled with voice services, small device type (which really means low transmit power and small antenna) and you have the right combination to make a phone tricky to get working properly.
There's a range of phones purpose built to work with Wi-Fi - from the older Cisco 7925, the newer Cisco 8821's and the Spectralink range of phones (notably the larger screen Versity's), there's a wealth of devices that you might come across in the field.
It's also becoming more usual to find standard end user devices - iPhones and Android phones - running soft clients.
The original question for this blog is how to fault find these devices - and it's not that easy. Really you have to work through the whole list above, then finally debug the device - and trawl that debug looking for the error codes.. that takes a while as you can imagine.
ASSOCIATED BLOGS:
The evidence gathered will depend on the type of review we are undertaking - whether it be to discharge a tender, or help fix up a non-working Wi-Fi network.
We can dig deep with debugs and sniffs, or just confirm if a survey was fit for purpose (and often they are not - there are many ways to incorrectly undertake a survey and waste your money on an ineffective result).
In the end, the outcome is hard knowledge, derived from following a well trodden process of fault finding. This is used to fix the network and get you back to a working state - which is what the network was designed for in the first place.
ASSOCIATED BLOGS: