Troubleshooting with Wyebot

Troubleshooting with Wyebot

I have written about Wyebot and some features you can use in my previous blog post. I also talked about a couple of use case scenarios. In this post, I want to review correlation and troubleshooting steps using the Wyebot interface.

Let’s look at one of the Wyebot sensor. Below, I summarize all the issues it is showing.

Wyebot dashboard shows the first issue related to a client device not being able to connect to an 802.1x SSID. When looking at the details of the client, I can see the client’s name, MAC, BSSID, SSID information. And I can see that it is failing EAP TLS. These alerts can be very useful when you are trying to be proactive. This is just a test environment with few clients. Imagine an environment where multiple clients experience this issue. This alert in the Wyebot dashboard can help proactively view the issue and narrow down the root cause.

I’m able to get a little deep into troubleshooting and download the pcap file for further analysis. Image below is a quick example showing the BSSID and the client EAP exchanges.

Next message is showing Legacy 802.11b data rates being used on the WLAN. Lower data rates get disabled in high-density environments. Even in low density unless there is a very specific need to keep the low data rates enabled they get disabled. Lower data rates can cause overall poor performance and user experience. For example, clients can stick to an access point and refuse to roam to a better access point.

If these clients move away from the access point, their RSSI will decrease and they will negotiate a lower data rate; this results in clients that are closer to the access point also suffer on that channel.

Similar behavior can occur in 5 GHz band (NOTE: this also depends on the deployment and other factor) when using lower data rate, such as 6 Mbps. How can this be useful? Proactively, Level 1/Help desk agents can find out the issues related to low data rates, sticky clients and roaming.

Next reported issue I’d like to discuss is, “Optimal 5GHz wireless channel plan not being used.” Look at this excellent chart; it shows that 5 GHz band has 25 – 20 MHz non-overlapping channels. If you want to use 40 MHz channels, that number drops to 12. What is this image below telling us?

Not only it is showing that the channels’ different access points are on, but also telling us that there aren’t any DFS channels being used; which means there are only 4 available channels. This kind of deployment can lead to high interference and poor client performance. Looking at this data, a WLAN engineer may proactively decide to enable UNII-2 and UNII-2c channels or use 20 MHz channels.

Last issue I’d like to talk about is “primary channel mismatch”.

When using 40 MHz channels, there is always a primary channel and a secondary channel. Management frames use the primary channel, data will use the secondary channel when the primary channel is full.

When using 40 MHz channels and you don’t have enough channels to work with, it can lead to “Primary/Secondary OBSS”. One access point’s primary channel overlaps with the second access point’s secondary channel. There is a lot to be discussed on this topic but fall out of scope of this post. However, I would like to share this link with some good information on “Overlapping APs capacity Sharing” should you be interested in reading more. Another great resource for understanding the “Primary/Secondary OBSS” is from my friends at “Clear to Send” with guest Devin Akin.


Using sensors such as Wyebot can be extremely beneficial when trying to troubleshoot issues and/or operating a large WLAN environment. Just like Wi-Fi, WLAN engineers have only so much time and capacity to accomplish tasks. Improving efficiency of the engineer and WLAN are two key factors we are talking about. Using sensors like Wyebot can help with the overall efficiency of the WLAN engineers and the user experience using the WLAN. Just a few things sensors can help with:

  • Validate your WLANs performance after the install
  • Part of the monitoring and operating a WLAN tool
  • Proactive and remote troubleshooting

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

WordPress SEO