This blog post is intended to be your guide and constant reminder of my Onion Approach to WiFi Troubleshooting. It's actually my personal notes to WiFi troubleshooting that has expanded over time and really geared towards my own comfort level. I share this here because readers of my frame analysis blogs and packets never lie video https://www.youtube.com/watch?v=Kn4hVq5vI3E often ask where do you begin when faced with wifi issues.
I plan to share a number of real world scenarios this one in particular The Help Desk Ticket.
What is the Onion Approach? An onion has many layers and sometimes you need
to break down your problems layer by layer. Case in point when I have a problem with a complicated configuration I take it all out of the mix and start to layer the complexity back on to see where it breaks.
Good troubleshooters have a method to their madness. We've all had that experience working with someone who just isn't that good at troubleshooting and struggles. Many times they do the same thing over and over expecting a different result while only wasting your time and theirs.
Albert Einstein said the definition of insanity is doing something over and over again and expecting a different result.
Long long ago when I started my journey in WiFI I recall quite vividly the frustration and struggle I had when troubleshooting WiFi issues. I would chase my tail and go down rabbit hole after rabbit hole, whenever I seen the slightest thing not right I would quickly and a abruptly see that as my "issue" and I would fall again in another rabbit hole. My confidence was taking a beating. I knew in my mind I was wasting my time and my users time. Back in those days WiFi was more a novelty.
Fast forward many years later I've learned a lot. Not just about how WiFi works, but I learned some of the best WiFi engineers are the ones who have great social skills. Engineers who interact with users, asking the right questions, and knowing based on those answers to formulate next steps.
I've always said. Unlike any other networking position WiFI takes the engineer out of the cube. When was the last time the routing/switching guy had to talk to nurse Betty ? How about the security firewall guy, how often does he need to interact with Dr. John.
Onion Approach - Help Desk Ticket
My thought process when a trouble ticket comes in.
1. Review help desk ticket notes:
User xyz is complaining wifi is slow. User in north tower 4th floor. Client supplicant appears to be configured correctly. Wireless MAC address xxxxxxxx
Sadly some help desk people aspire to be and do more and add detailed notes and preform basic troubleshooting. While others act more like a call center and their purpose in life is if it doesn't fit their understanding or knowledge they just shuffle the ticket along. Let me get off my high horse before I get in trouble.
2. Check status of the North Tower
- Access points down; No
- Any recent changes like construction ; No
- Any firmware updates to the controllers; No
- Any client pushes or updates via GPO;No
3. Check client wireless mac address
- Check monitoring system for any possible issues
- Check client connect history
- Check what areas the device typically associates to
- Check radius logs
4. Check user ID
- How many devices is the user using on wifi
5. Call user - Questions to ask:
- What device
- What driver
- How often does the issue happen
- Can you reproduce the issue
- Does anyone else have the issue
- Does any of your other devices preform in this same manner
- When did this issue start happening (yesterday, last week, last month)
- Is there a particular time of day the issue happens
- Can you share exactly the location you are having the most problems in
- Is there a particular app in use when you observe the slowness
- Any changes recently to your device that you might think contributes to your issue
- What wireless network do you connect to
6. Visit Floor
- Try and reproduce the issue on your device
- Observe the user while collecting debugs, logs and frame captures as needed.
- Speak to other users in the area specific to their experience
- Get an exact build of that device and test
While sharing a pretty comprehensive list most times we pick and choose which questions to ask based on the relative answer to the question posed. Most times busy users don't have the time nor the patients so be precise in asking your questions. If I find the device is not on our supported driver and supplicant configuration doesn't match our standard that's the first thing that gets fixed.
I hope you enjoyed this blog post. Thank you