Wi-Fi PCAP with Ekahau | mrn-cciew

In this post, we will see how you can use the Ekahau Sidekick (1 or 2) to take Wi-Fi packet captures. The Ekahau Sidekick 2 has 4 Wi-Fi adapters (tri-band – 2.4/5/6 GHz). This allows you to use the SK2 to capture traffic from 4 different channels simultaneously (continuous PCAP).

Wi-Fi PCAP with Ekahau | mrn-cciew

If you have the sidekick1, then it got 2 x Wi-Fi adapters (dual band – 2.4 and 5GHz)

In the early days, you had to use the ‘Ekahau Capture application to take PCAP using the SK1. However, it is no longer a supported application from Ekahau (it may still work on older Windows devices). Going forward, Ekahau recommends using the ‘Ekahau Analyzer‘ application to take packet captures. This means you will need to use a phone or tablet to run the ‘Ekahau Analyzer’ application while the SK1 or SK2 hardware is connected to that device.

Currently, the ‘Packet Capture‘ feature is only available on iOS devices (i.e., Apple products). Therefore, you need to have an iPhone or iPad for this to work. You must open the ‘Ekahau Analyzer’ application (you will need Ekahau Cloud login credentials) and connect the SK1 or SK2 to your iPhone or iPad. Once it is properly connected and powered on, the sidekick icon should turn green. If you click on that icon, you can adjust the basic settings. If you would like to take a full PCAP (rather than packet slicing), you must enable that option before capturing the PCAP.

Once you select the ‘Packet Capture‘ option, you can start a ‘New Capture” and select your channels. I have shown CH44 and CH21 in the below example.

You can capture a PCAP for a maximum duration of 5 minutes. If you can reproduce your issue within that time, you should be able to capture it. Especially in client roaming troubleshooting scenarios, capturing 4 different channels continuously is a significant advantage. Once you took the capture, you can share it via many different methods (Airdrop, Webex, WhatsApp, etc)

If you select more than 4 channels, the Wi-Fi adapters must scan each channel for a short period (known as dwell time) before moving to another channel. In my home lap setup, I got 3 UniFi APs.

I have selected all those 8 channels (two screenshots taken as all channels won’t display on one screen of the phone). The file name is in the format of ‘16Oct2024_210707_126_SK2_[1,11,60,100+4more].pcap‘.

If you look at that capture, you can see that you do not have beacon frames for the given SSIDs consistently (roughly every 102.4 ms). This is because the 4 Wi-Fi adapters of the Sidekick must stay on one channel for the dwell time before moving to another channel, which causes you to miss beacons from the previous channel.

Let’s take a PCAP on 4 channels where you can capture continuously. Here is the test setup, and I have not shown all 3 UniFi APs in the diagram.

Since ‘mrn-u‘ SSID operates in 6GHz, let’s capture those 3 channels (37,53,69) and CH149 in 5GHz which is MRN-UAP3 which is closest to my client devices. Here is the file captured using SK2 ‘PCAP 16Oct2024_213608_135_SK2_[149,37,53,69].pcap‘. Since my SSID is 802.1X, if you filter EAPoL traffic you should able to see EAP/4Way-Handshake of my client association.

This time as well, I have run that WlanPi multichannel capture with Airtool2, if you like to compare both PCAPs as well.

In that capture (airtool_U7pro_BE200_1X.pcapng) as well you can also see those EAPoL traffic. I can see 34 frames whereas in the SK2 capture saw 36 frames.

Since we are capturing over-the-air data, especially with WPA3, most of the management frames are protected. As a result, you will not be able to understand what those individual action frames are. Therefore, if you have two PCAPs (one with AP as sniffer – like Meraki, Mist, UniFi) and another over-the-air capture placed close to clients will be helpful