Onion Approach To Wi-Fi Troubleshooting Basics: 3 Areas of Focus when Troubleshooting Wi-Fi Issues

By George Stafanick, Blog Contributor

Hello and welcome back to another "Onion Approach To WiFi Troubleshooting." I wear multiple hats as a Wi-Fi engineer and you probably do too. Wi-Fi is a black box to many folks and because of this, it’s easy to blame when Wi-Fi users have problems. If you spend any amount of time managing a Wi-Fi network large or small you know what I’m talking about. Troubleshooting Wi-Fi isn't necessarily difficult if you know where to look. As Wi-Fi engineers, we aren't afforded the luxury of plugging in a cable and it just working.

When issues arise do you know where to look after you do your initial discovery?

You just completed your initial discovery. You spoke to the users and collected your notes. You may or may not be able to reproduce the issue. Where do you go now?

There are three main areas you should consider as your next steps to troubleshooting. We need to look at what the device says, what the ap/controller says and last but not least OTAC over the air captures. Many times when you combine the data collected from all three, a story starts to develop.

Let's dive in!

Wi-Fi Device

It is no secret Wi-Fi clients are the bane of our existence. Because there are no teeth in the 802.11 standard specific to Wi-Fi client function and behavior, vendors can choose to implement their own secret sauce. When looking at the Wi-Fi device here is a short list of items to looks at:

  • Window Event Logs

While the event codes may not be consistent between REVs of NIC (ie Intel 7260, 7265, 8260) you can start to collect the codes for each NIC. The event logs will paint a picture specific to what the OS and WLAN is doing.

Nurse Betty got kicked off the Wi-Fi network around 11:30pm. Check the log and see what it says are that time. You might be surprised what you might find!

Recently we fought an SSO (Single Sign On) issue. The SSO logs showed it didn't have network connectivity to authenticate to the vault, but the windows event logs showed it authenticated and pulled an IP address. Of course the application folks blamed the Wi-Fi network. The event logs allowed us confidence we can send this issue back over the fence to have the SSO application folks to relook at their problem.

  • NETSH commands

A quick google search of NETSH and you will find a lot of resources including blogs and videos showing how to use NETSH and the commands. You can pull a considerable amount of information from the driver.

CWNP’s Tom Carpenter did a great video to help you get started:

I had the privilege of speaking at ATM15 Ten Talk on the subject of WiFi drivers and devices.

Remember what you are seeing from this side is only one view of the overall picture. It is the Wi-Fi clients perspective of the network.


  • Debugs

No big surprise here. When you have wireless issues most folks start right here. Many times you can find clients misbehaving, failing authentication, and doing odd things. Remember what you are seeing from this side is only one view of the overall picture. It is the controller's perspective of the client.

OTAC (Over the Air Captures) 

I can tell you from years of experience radios (clients/APs) may say they are behaving per their logs, but sometimes the frame captures tell a different story. Frame layer analysis requires a particular skill set and special software and hardware to collect frames over the air.

If you want to learn more about 802.11 frame analysis check out my ATM15 Packets never lie: An in-depth overview of 802.11 frames

Remember what you’re seeing from this side is what both sides are saying. Warning — don’t jump to conclusions or have a knee-jerk reaction based on what the frames are showing. You want to collect all the information from all side to have a good perspective.