There comes a time in every WIFI professional's career when the need to solve or explain a situation can only be accomplished by viewing direct evidence. This is especially true when moving beyond "break/fix" and into root/cause analysis. As the saying goes: "Its not what you know, its what you can prove" I can tell you that that in my experience of over 20 years in technical support, I have learned that while many just want to move on and are satisfied to just have the problem solved. I have also learned that you may often get lucky and solve problems by educated guessing, making inferences, and using the tried and true methodology of:
Identify the problem.
Discover the scale of the problem.
Define the possible causes of the problem.
Narrow to the most likely cause.
Create a plan of action or escalate the problem.
Perform corrective actions.
Verify the solution.
Document the results.
However others, especially leaders, demand a full explanation and reason. Some people are simply not persuaded and may not trust your word that the issue is resolved and will not happen again. Educated and experienced leaders did not get where they are by relying on the word of strangers. Trust is something that needs to be earned and sometimes there isn't enough time to earn that trust when working a problem in the company of strangers for the first time. In conclusion, seeing is believing.
A quick overview about WIFI channels
If you have practiced and studied any kind of WIFI technology, then you know that communication occurs over specific frequency bands (2.4 or 5ghz) and those frequencies are further divided up into smaller bands, which we call channels. WIFI channels work similar to channels on an old television set. Each TV channel has a number and you can only watch one channel at a time! With 802.11, each channel is identified and counted by its center frequency, which is 5Mhz apart from each other. Consider the US 2.4GHz band for a minute (refer to figure 1). The US 2.4Ghz band is 83Mhz wide starting with 2.401GHz and ending with 2.484GHz. The standard says that each channel must be at least 20Mhz with a 2Mhz Guard Band (total of 22Mhz wide per channel). Furthermore, the standard calls for an additional 3Mhz for spacing between channels. This means that in reality, with only 83Mhz to work with, and given the mandate of 22Mhz + 3Mhz between channels, we only have 3 usable channels for communication out of the 14. Those usable channels are 1, 6, and 11. How much data we can pass through and the speed at which is moved is determined (and limited) by the width of our channel.
If your head is spinning right now, simply subtract each center frequency from each other, for example: The center of channel 6 (2.437GHz) - the center of channel 1 (2.412GHz) = 25MHz. So you can see there is no way we can get any more than 3 channels out of the 2.4Ghz band with them being 25Mhz apart.
When we configure our WIFI hardware to support channel bonding, i.e. combining channels together to increase throughput, we double the channel width each time we do it.....for example going from 20Mhz to 40Mhz to 80Mhz to the max available, 160Mhz channel width. Doubling up on the channel width boosts performance considerably but comes with a price however. Each time we double the channel width, we half the amount of available channels our clients can use to communicate. This can cause problems given the half-duplex nature of WIFI in 802.11ac and earlier standards given we cannot send and receive at the same time and only 1 client can communicate at a time .
Configuring channel bonding on the 2.4Ghz band is not recommended as it is mathematically impossible to have more than 1 channel for client use in this configuration
Given the limited numbers of channels in the 2.4Ghz band, the industry gave us 5Ghz which provides 23 non-overlapping channels which gives us more wiggle room. With 5GHz, we get up to 6 non-overlapping 80Mhz channels and the up and coming 6Ghz band, we will get 14 non-overlapping 80Mhz channels. As for the maximum channel width of 160Mhz, the 5Ghz has some limitations such as the fact that enabling it divides the entire spectrum into only 2 usable channels which means if a neighbor in range is also using 160Mhz, your clients are not going to be able change channels, significantly impacting your wireless performance. 6Ghz on the other hand gives us 7 non-overlapping 160mhz channels which allows us for the first time to really and comfortably unleash the full potential of wireless communication.
Capturing Wireless Traffic (per Channel)
Going back to the example of the old television set and just being able to watch 1 channel at a time, similarly, when capturing wireless traffic over the air, we have to be capturing the same channel the client is on or we wont see the client communication. That presents another issue, how do we know what channel the client is on? Even if we know the channel at the start of the initial capture, if the client changes its channel, for example, during roaming, we wont see the communication until we change to match which may be too late by the time we notice. We need a way to capture as many channels as we can simultaneously in order to successfully narrow down client side issues such as Fast Secure Roaming problems for example.
Building my Wireless Capture Rig
In this example we keep in mind the challenges Microsoft OS brings when it comes to performing OTA capture and choose a NIC that supports both promiscuous mode and monitor mode.
Hardware:
1x ACASIS 10 Ports 48W USB 3.0 Data Hub
6x Edimax EW-7833UAC AC1750 Dual-Band Wi-Fi USB 3.0 Adapter
6x AINOPE USB 3.0 Extension Cable Type A Male to Female Extension Cord (6FT)
1x Omni Ultimate 38,400mah AC/DC/USB-C Powerbank
1x Windows Laptop
Software:
MetaGeek Eye P.A.
*Note - MetaGeek Eye P.A only supports scanning/capturing up to 6 channels at a time.
Using a piece of cardboard, I mounted the 6 network adapters into it connecting one end of the USB extension cable from the bottom to keep them in place and the other to the hub.
Verified all my Wireless NIC's were detected in installed in Windows Device Manager:
Started MetaGeek Eye P.A to configure each NIC to capture a specific channel:
