There are many possibilities of taking packet capture to troubleshoot a wireless or wired network or application issues.
Before you take a packet capture, there are several tips, which can save you a lot of time and money.
1. Check details of the WLAN adapter / AP
Nowadays there are 2nd wave 802.11ac capable APs in the market. Many companies have older 802.11n or even 802.11a/g APs deployed in the production environment.
When taking a packet capture, you should consider what protocols and APs are installed.
Every new protocol is backward compatible with older technologies, which means you can collect 802.11a/b/g frames with 802.11n/ac adapters. This is obvious.
However, you can’t collect 802.11n/ac frames with 802.11a/b/g adapters or APs.
1st wave Aruba AP with 802.11ac operating on channel 48. One laptop and one mobile phone associated.
First capture is taken with MacBook Pro with built-in 802.11a/b/g/n card only with Airtool. I added PHY type as a column to see differences (wlan_radio.phy):
Only management and control frames are seen with 802.11a data rates, no 802.11ac data frames.
As a comparison, second capture in the same environment was taken at the same time with another MacBook Pro with built-in 802.11a/b/g/n/ac card with Airtool:
2. Check what channel widths are used
There is a reason why 40 or 80 MHz channels are used and it is a faster connection.
If 40 MHz channel is used, this doesn’t mean that only 40 MHz mobile clients will be associated to the radio. Clients may send data frames with 20 MHz or 40 MHz width, while management and control frames will be sent at 20 MHz channel width on primary channel.
AP transmits with 60+ channel, packet capture taken only with primary channel 60.
2 x mobile clients associated: laptop with MAC address 28:16:ad:2f:ec:5c transmitting only 20 MHz data frames and mobile phone with MAC address cc:44:63:1b:2d:fa transmitting only 40 MHz data frames.
There are only management and control frames for the mobile phone with 802.11a. No 40 MHz 802.11ac data frames seen obviously.
On the other hand there are laptop’s data frames as those are transmitted with 20 MHz channel width.
The second packet capture with the proper 60+ channel:
I added a VHT Information -> Bandwidth (radiotap.vht.bw) to show 20 MHz and 40 MHz data frames. Now we see communication intended for laptop and mobile client as the proper channel has been selected.
3. Capture multiple channels from one adapter = bad idea
As an example, Wireshark or Airtool allows an user to capture traffic from more than one channel.
Channels 1, 6, 11, 60 and 64 were selected.
5 channels were selected, therefore the capture jumps from one channel to another one.
In this example each channel has 1/5 of the second to capture the traffic. Any conclusions based on such a scan might lead to wrong decisions.
If you need to scan channels 1, 6 and 11 and a reason for that is mobile client’s roaming problem, it is good practice to use 3 x separate adapters. In such a scenario one adapter should be dedicated for specific channel.
4. Check time in the network
Before taking a packet capture, it is good idea to check if all network devices (not only wireless controllers and access points) have the same time. The easiest way is implementation of a NTP server.
Laptop’s clock was misconfigured and a few moments later packets were captured.
In the meantime a wired packet capture were started:
Merging both files in Wireshark will lead us to false conclusions.
This is why usage of NTP server is so important for troubleshooting.
Using best practices for Wireshark will help in troubleshooting and analysis. I always spend a moment to think what I want to capture, on which channels, on which channel widths etc. Preparing myself for a problem replication saved me a lot of time on customer premises in and in my lab.