Hello and welcome back to another Onion Approach To WiFi Troubleshooting. I wear multiple hats as a WiFi engineer and you probably do too. WiFi is a black box to many folks and because of this, it’s easy to blame when WiFi users have problems. If you spend any amount of time managing a WiFI network large or small you know what I’m talking about. Troubleshooting WiFi isn't necessarily difficult if you know where to look. As WiFi 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.
Lets dive in !
WiFi DEVICE
It is no secret WiFi clients are the bane of our existence. Because there is no teeth in the 802.11 standard specific to WiFI client function and behavior vendors can choose to implement their own secret sauce. When looking at the WiFi device here is a short list of items to looks at:
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 WiFi 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 WiFI 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.
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:
https://www.youtube.com/watch?v=vYbtiY3bnTM
I had the privilege of speaking at ATM15 Ten Talk on the subject of WiFi drivers and devices.
https://www.youtube.com/watch?v=CT42g8l56LE&t=25s
Remember what you are seeing from this side is only one view of the overall picture. It is the WiFi clients perspective of the network.
AP/CONTROLLER
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 controllers 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
https://www.youtube.com/watch?v=Kn4hVq5vI3E
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.