I started my IT career career as help desk support where I started as level 1 engineer at an MSP (managed service provider) to help troubleshoot WiFi connectivity on endpoints. Since then, I have worked several roles supporting many large enterprise customers and learned several tips over the years which I want to share on this post.
Packet Captures
Packet captures are my go-to when I'm faced with any complex troubleshooting scenario. When I used to work at Cisco Meraki as Network Support Engineer, this is the tool that I relied heavily. For the most part, there is a saying, packet capture never lies. Or follow the packet to find the root cause of the issue. I used to take packet captures on multiple devices on the network path simultaneously to ensure I have enough data to troubleshoot the issue.
One of the issues that I often faced is to get packet capture for wireless interface. Some of the devices I used to support when I was in support, it did not support promiscuous/monitor mode packet captures. So, we used to always ask the customer to use a MacBook to perform monitor mode packet capture. That way, we would be able to collect all information that is being transmitted in the frequency the AP is operating.
Once I have the packet capture, I would be able to look at different information such as reason for disassociation, phase of connectivity that's failing (association, authentication, DHCP and DNS resolution, etc), TCP connection information, retransmits, roaming, and many other types of issues.
Accurate scoping of the issue
It may sound very straightforward but I feel like this is an important topic to remember when it comes to any troubleshooting but this applies specifically to 802.11 wireless. Wireless issues can be very vague at times, especially non-technical users where they may describe the issue totally differently than what could have been the issue. I have had many calls in my IT career where the end users would complain slow WiFi but the problem would actually be related to something regarding what they are doing with their application, or it might even be expected behavior as they may be transferring large set of files over a wireless network using 2.4 GHz frequency.
It is important to ask clarifying questions to be able to fully understand the issues. Some of the examples could be -
- Can you explain what process is slow on the application you are using?
- How are you connected to the internet?
- What is the device you are using to connect?
- What is the expected performance/outcome you are trying to achieve?
- Did you make any changes recently?
- Has this issue recently started occurring? How often do you see this issue?
Questions are situation dependent, but I wanted to provide some examples.
Learn how to read MCS Index.
I cannot recall how many times I had to take calls to troubleshoot slow Wi-Fi network and at the end the issue was 'expected behavior' when it comes to wifi. WiFi works differently than wired ethernet where WiFi is not full-duplex medium. There are several other nuances that you would need to consider like which technology the client and the AP is capable of, signal strength or signal to noise ratio, number of clients on the AP or total airtime utilization, modulation, etc.
MCS index is a great tool that we can use to set the right expectation to a technical savvy user where we can explain how the data rates are calculated based on many different factors. Even when we determine the data rate, we should also set expectations that there is also an overhead for the protocols that they may be using to perform that speediest. It is a great tool to have for any engineers who is troubleshooting wireless performance issues.
Here is the MCS Index that I use.
These were the three main tips that I wanted to share. Of course there is a lot more when it comes to wireless troubleshooting. I hope to continue to share more information in my following posts!