Blogs
The software of the WLAN infrastructure should always be kept updated. Unlike other network equipment – like wired switches – the software on WLAN equipment is constantly changing. The WiFi industry is very dynamic and vendors must keep up with new standards and certifications.
Administrators must use techniques such as reducing AP radio power, removing lower data rates and disabling some radios on 2.4GHz. On 5GHz, channel widths should be reduced to 40 or 20MHz. DFS channels should also be used to ensure enough unique channels. Bandsteering should be enabled to move clients onto 5GHz radios. It may be tempting to remove networks from 2.4GHz altogether, but as previously mentioned there are still many IoT and wearable devices that only support 2.4GHz. Separate SSIDs can be created for these devices and the main production SSIDs can be on 5GHz only.
Rather than combing through packet data and eliminating scenarios one-by-one, it would be far more efficient – and far less frustrating – if the cause of the problem were known immediately. This would lead to faster resolutions, improved user experience and allow IT staff to move on to other tasks. With Wyebot’s WIP, there’s only one troubleshooting scenario regardless of the problem:
Troubleshooting WiFi – How to Resolve Poor WiFi Experiences in Enterprise Networks
August 27, 2018
All IT professionals are familiar with variations of the “WiFi isn’t working” complaint. Determining the root cause of network connectivity issues can be time consuming, even more so if the initial reported problem cannot be replicated. This guide will first walk through the traditional methods used to troubleshoot WiFi issues and then how to troubleshoot the same issue using Wyebot’s Wireless Intelligence Platform ™ (WIP).
Challenge Number One: Capturing the Problem at the Right Time
Wireless users face problems while running typical cloud applications, transferring files, streaming and other normal daily activities. When a problem occurs, ideally IT staff is available to collect data immediately for analysis, problem identification and resolution. However, we know this rarely the case. For some IT professionals, the more common scenario is that the problem is reported after hours or on the weekend. Higher education campuses report peak network usage is between 10pm – 2am. Different time zones can cause problems for IT teams responsible for multiple national or international offices. The inability to capture data at the time of a disruption greatly complicates eventual resolution. In some instances, problem replication might be impossible. While this could mean the issue has resolved itself, it can be frustrating for the client and IT because there’s no way to be sure the problem will not reoccur.
Even in situations where the problem could not be replicated, it is good standard operating procedure to gather basic, defining information surrounding the issue:
-
Number of clients experiencing the problem
-
Device types, hardware and drivers
-
Specific location and APs affected