Capturing client traffic on Aruba Campus and Instant Access Points using Wireshark

Welcome to my first blog entry! This is going be a fun, and no doubt educational experience.

The purpose of this blog is to document my experiences and lessons as I journey through my career as a Wireless Professional. As this is a journey, I welcome my fellow travelers and their input. I welcome any feedback on improvement, and corrections on any mistakes made.

With that let’s get to my first topic: Recently I have had the privilege of taking the CWAP bootcamp at the Wireless LAN Professionals conference in Phoenix, taught by one of the CWAP PW0-270 Certification Guide Authors, Peter Mackenzie. Through the course and in the subsequent studying, I have learned the value of capturing 802.11 traffic. My previous experience had been strictly in capturing wired traffic using wireshark, and had only briefly touched on 802.11 MAC headers in studying for my CWSP certification.
I am still in the process of building my own setup where I can capture directly from a notebook, but in the meantime I utilized the Dell Powerconnect-W(Aruba OEM) equipment in my work lab and put together a small configuration consisting of a Campus AP, an Instant AP, local controller, capturing notebook running wireshark, and test client that can connect to my test SSIDs.


1 Aruba 7030 controller – Firmware version
1 Aruba 225 Access Point – IP, AP name is Shark_test
1 Aruba 225 Instant Access Point – IP AP name is Shark(I’m super original). Firmware version
1 Test client, Wireless MAC is 00:21:5c:70:12:4f. WLAN IP is We will be capturing packets from this device.
1 Wireshark monitoring notebook. IP address
Campus SSID is Shark_test
Instant SSID is Shark_test2


2018-03-26 08_47_40-Diagram - Visio Professional

The purpose of this demonstration is to show how to capture client traffic for troubleshooting analysis. The actual Analysis of the packets is not covered in this blog entry.

Many characteristics of client behavior can be learned through capturing the wireless communication between the Access Point and the wireless client. Management, Control, and Data Frame Packets provide a wealth of information in their MAC-layer headers. Such details as signal strength, client capabilities, QoS parameters, authentication and association details, roaming processes, and more can be ascertained through this form of monitoring.

The 802.11 standard exists at the Link layer and the MAC sublayer of the Data Link layer in the ISO model. For that reason, we need to capture the communication details between the Access Point and the client Radios. With a traditional packet capture using promiscuous mode, we are capturing the 802.3 Ethernet communication and the layer 3 information between devices. For the purposes of wireless troubleshooting, we need to have the wireless network card in “monitor mode”. This is an RF listening mode that will not only allow us to 802.11 information, but it will hear all nearby transmissions as well.

Ideally, you would want to capture the packets using a notebook and WLAN card being as close to the client device as possible. But if a WLAN card is not available, or you are not onsite, the next best thing is to capture at the access point.

Aruba Access Points allow packets captures by essentially making a copy of the of the packet and forwarding it to your capturing device. They are encapsulated in a UDP header address and use port 5555. We will talk a bit more about this during the configuration setup.

To perform the packet capture process, do the following.

  1. Find the client MAC address
  2. Find out what Radio and AP that the test client is associated with. Radio 0 is for 5GHz, and Radio 1 is for 2.4GHz. You can run show ap association client-mac <mac address of client> in the CLI to find out this information. If you have access to the windows client, you can alternatively issue the “netsh wlan show interface” command at a command prompt to learn what BSSID and channel that windows client is in.

2018-03-19 09_52_33- - Remote Desktop Connection

From the above screenshot, you can see the client is associated to the SSID Shark_test and is on the 5GHz band, channel 36.

You can also find the client in the GUI:

Go to Monitor > Client > then enter the MAC address in the search field. Or whatever character you want to use for a search.

2018-03-15 13_58_10- - Remote Desktop Connection

For this test, the client MAC address is 00:21:5c:70:12:4f

As can see the test client MAC address is 00:21:5c:70:12:4f, it is connected to an AP named Shark_test and it is using the .11a radio, or radio 0. These parameters will be used in our capture.

Important Note: The packet capture is initiated by the controller, but the captured packets will not go through the controller; they will be routed from the Access Point to the capturing PC station. So, it is important that you can make sure that your Access Point can route to the PC that you are capturing to. The simplest method to determine this is to ping the access point from the capturing device.

To start the packet capture process from the GUI, go to monitoring, Access Points, and then select your Access Point and click on the packet capture button:

2018-03-16 13_04_21- - Remote Desktop Connection

In the next window, we will want to select BSSID that we will be performing the capture from. In our case, we will select the 802.11a-VHT radio, as our client is connected to the 5GHz channel 36.

2018-03-16 13_06_25- - Remote Desktop Connection

Select a new Raw Packet Capture:

2018-03-16 13_07_32- - Remote Desktop Connection

Note: If you are using Wireshark, then you must do a Raw Packet Capture. The reason is the way that the AP sends the packets to the capturing device. The capturing method isn’t an exact mirrored process. The AP will make a copy of the frames that are being transmitted and received. In doing so it fails to append the four-byte “frame check sequence” (FCS). This was remedied to allow format 1 and 3 to include the FCS. This is discussed on the Aruba Airheads forums: and here:

Only a Raw packet capture will allow you to change the format. I personally like the Peek+11n/11ac header(format 5) because it provides detailed HT information that is more specific than number 3, which is the pcap+radio header and doesn’t have the malformed problem that format version 0 has. It also makes it so that you do not have to use the PEEKREMOTE decode in Wireshark(See Paul Stanley’s YouTube Video, referenced at the end of this article).

Formats that will work for Wireshark are 1,3, and 5.

Enter the following into the highlighted fields:

2018-03-16 13_12_36- - Remote Desktop Connection

  1. Target IP: this is the IP address of the PC that will be performing the packet capture. You should have already verified that the PC can ping the Access Point’s IP address.
  2. Port: This is the port that Wireshark will be listening on. You will use 5555 for Wireshark. If we were using OmniPeek, we would use port 5000.
  3. Format: I prefer Peek+11n/11ac header. This is the best option to get the most information about HT devices. If you are troubleshooting legacy devices, then option 1(pcap Ethereal) or 3(pcap+radio header) will work, though in my troubleshooting I have seen that option 1 will show the current data rate whereas option 3 will not. Setting the option to Peek+11n/11ac will also make it so you do not have to use the PEEKREMOTE decode in Wireshark.
  4. Choose the radio that you will be listening in on. Our client is on channel 36, so we will be listening on the 802.11a radio.
  5. Channel: This can only be set if you are capturing from an air monitor. In our case we are capturing from an access point, so we will leave this field blank.
  6. Maxlength: we want to be able to capture Aggregate MPDU’s, which are usually between 3839 to 7035 bytes, So I left plenty of overhead in there.

To set up capturing in the CLI, perform the following commands. Remember that our PC runing wireshark has an IP address of, our Test AP has a name of Shark_test. We need to use port 5555 and option 5 for the Peek+11n/11ac header format.


(Local_7030) #ap packet-capture raw-start ap-name Shark_test 5555 5 radio 0

Packet capture has started for pcap-id:25

Take note of the pcap-id, as you will need that to stop the packet capture from the CLI. Example:

(Local_7030) #ap packet-capture stop ap-name Shark_test 25

Viewing packets on Capturing PC using Wireshark

Moving on to our capturing PC. We will open up Wireshark and enter a capture filter of port 5555, as we need to be able to view only the wireless captured packets and not any erroneous packets that enter the Ethernet port.

2018-03-16 15_38_13- - Remote Desktop Connection

After selecting the local area connection and starting the capture, you will see the captured data. You can use the filter wlan.addr==00:21:5c:70:12:4f to filter specifically for the client that we are troubleshooting.

2018-03-19 10_18_51- - Remote Desktop Connection

For additional filters, you can use the following reference sheet:

Capture Filters

Wireshark Filter Photo attributed to of Keith Parsons and Wireless LAN Professionals Organization.

Important note: An Access Point can only run a single capture per radio, and it will not be able to capture the roam to another Access Point. So, if you are troubleshooting client roaming issues, it might be best to also run the packet capture on any neighboring Access Points. Example.

2018-03-19 12_38_56-Drawing1 - Visio Professional

Capturing Packets from an Instant Access Point

The steps are similar when capturing from an IAP, but the whole process must be done at the CLI:

  1. Connect to the IAP GUI and see what SSID and channel your client is connected to:2018-03-19 13_22_45- - Remote Desktop Connection
  2. Connect to the CLI of the IAP. This must be the Actual IP address of the IAP that the client is connected to, and not the Virtual IP address of the controller.
  3. Determine what BSSID the client is connected to by issuing the show ap bss-table command:2018-03-19 13_25_17- - Remote Desktop Connection
  4. Enter the following command format into the cli:pcap start<ip address of capturing device>
    In our scenario, it would look like this:pcap start ac:a3:1e:ac:6b:d3 5555 3 10000

Packet capture has started for pcap-id:1

I am using option 3 for pcap+header

Again, take note of the pcap id so that you can use it to stop the capture:

Shart_Test_IAP# pcap stop ac:a3:1e:ac:6b:d3 1

Packet capture has stopped for pcap-id:1

When you open Wireshark on the capturing device, you will notice that the source is the IAP, and the destination is the Ethernet port on the capturing device, the Info column is only showing port 5555. To see the packets properly, you will need to decode.

2018-03-19 13_33_32- - Remote Desktop Connection

Let’s decode the packets: Right-click on any of the packets and select decode as:

2018-03-19 13_35_34- - Remote Desktop Connection


2018-03-19 13_38_42- - Remote Desktop Connection

Now the packets appear normal!

Feel free to play around and let me know what you find. If you see any mistakes or what to share any input, then please let me know! I am always open to feedback!

The following sources were used as references for this article and lab:

CWNE 88 Paul Stanley’s You tube Video:

Airheads community Forum:

David Wescott’s book Understanding ArubaOS

Airheads community Forum:

Wireshark Filters:

Additional Wireless filters for Wireshark can be found at:

Recommended book to learning how to Analyze captured WLAN packets:,miniSiteCd-SYBEX.html

CWNP Program:


Coming Soon


My name is Lance Romigh. I am a Senior Networking Engineer at Dell Technologies. I will be using this space to further discuss my knowledge and observations surrounding a wireless world.