Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Collecting a Wireless sniffer trace using the Cisco Lightweight AP in Sniffer mode

Introduction

 

You can use the Cisco WLC and LAPs in sniffer mode, in conjunction with a wired sniffer (feature designed for AiroPeek/Omnipeek, but can work also with Wireshark).

A single wired sniffer can collect packets from multiple APs, so this method is very useful to run multi-channel traces. For static scenarios, if it’s possible to move the sniffer AP, this can be used as an effective alternative to other sniffing options.

For roaming scenarios, the sniffer APs are usually installed in the proximity of the APs the client roams through, and this will report the “point of view” of the static APs rather than the client.

In order to see the RF from the point of view of the client while roaming, a multi-channel wireless trace should be captured using a laptop with multiple Wireless NICs that will follow the test client.

 

Configuration steps

 

1) WLC / AP side

Here are the steps in order to collect a trace using a sniffer mode LAP

  • Configure the AP in Sniffer mode:

image002.jpg

 

The AP will reboot and it will not be able to serve clients.

  • Once the AP has re-joined the WLC, configure the radio of the AP (802.11b/g/n or 802.11a/n):           
    • specify the sniffer IP address
    • select the channel
    • enable sniffing

image004.jpg

  • The sniffer will receive the 802.11 traffic encapsulated using the airopeek protocol, from the WLC management IP address with source port UDP/5555 and destination UDP/5000

 

2) Sniffer side: Wireshark

If using Wireskark to receive the traffic, (Note: Please use the most current version of Wireless due to various decoding issues of past releases, Download Latest)  follow the steps below:

  • Set the capture options to receive only traffic on UDP/5555:

wireshark.jpg

 

This filter is optional but strongly recommended as it excludes all the non-wireless related traffic from the capture. Consider that the WLC sends traffic to a UDP port there’s no application listening on the sniffer side; this results in having a ICMP port-unreachable response for each packet received from the WLC.


Although this is expected, the filter above helps to exclude also this traffic which is useless and so it can only cause the trace to be bigger and more difficult to read.

  • Then, start the capture:

image007.jpg

  • The captured traffic has to be “decoded as..” AIROPEEK in order to be able to see the 802.11 traffic:

Note: In Wireshark releases 1.8 and higher, AIROPEEK has been renamed to PEEKREMOTE.

 

image009.jpgimage011.jpg

 

  • The 802.11 traffic will now be visible:

image013.jpg

 

The RF info shown above (e.g. the channel, signal strength, noise..) are added by the AP. Wireshark can decode only some of these elements, whereas OmniPeek will show all of them.

 

3) Sniffer side: OmniPeek

When using OmniPeek as the receiver of the traffic stream from the WLC/AP in sniffer mode, it’s first of all necessary to create a “Cisco Remote Adapter” under the “Adapter” menu of the “Capture Options” window:

image015.jpg

At least one adapter is required; the name is a mandatory field, whereas the “IP Address” field can be left blank if you don’t want OmniPeek to filter the incoming traffic from a specific WLC.

 

In this case it’s not necessary to filter out any traffic (such as the ICMP port-unreachable) as OmniPeek will listen on the UDP port to specifically capture the data stream from the Wireless LAN Controller.

 

Before starting the capture, confirm the settings on the main OmniPeek window:

image017.jpg

 

At this point the capture can be started and the result will be a trace including the RF info reported by the AP:

omni.jpg

NOTE: By default OmniPeek remote adapter picks up the timestamp sent by the AP itself; this info has nothing to do with the AP clock, so the resulting timestamp will be incorrect. If you use a single sniffer AP the timestamps will be wrong but at least consistent; this is no longer true if you use multiple APs as sniffers (as every AP will send its own timestamp info, causing funky time jumps on the merged capture).

  • Solution

You can explicitly tell OmniPeek to use the local sniffer PC clock to set the packet timestamp.

This solves both the single and multi AP scenario, having correct and consistent timestamps as long as the PC running OmniPeek has a NTP-sync’d clock.

  • How-to steps:

In OmniPeek, do the following:

1. Go to Tools>Option>Analysis Modules

2. Search for cisco remote adapter then double click to bring out the options.

3. Tick on the Timestamp option then click OK and test again the capture.

 

OP.png

 

Comments
New Member

Hi Tim,

Is the AP sniffer mode is available for autonomous AP SW, if so can you please address how to configure it.

Many Thanks

Cisco Employee

Sniffer mode is something that's only available in a controller AP environment.  But I do know its been a requested feature for the autonomous AP's

 

thanks.. Tim

New Member

Hi Tim,

 

Actually I was able to configure it manually but the Wireshark does not parse the data correctly, to configure it from AP cli you can set interface to mode monitor

Regards

Pavel

 

New Member

In recent Wireshark releases, the protocol is called "PEEKREMOTE" in the "decode as" menu.

Just for reference ;-)

Regards,

Jochen

Cisco Employee

For the NGWC deployments (3650/3850/5760) use the following commands in the CLI:

Controller# ap name <ap name> mode sniffer   (this will make the AP to reload)

After the AP reboots and joins the controller again, define which channel will the AP sniff (you can define one channel per band (one on 5GHz and one on 2.4GHz).  The final step is to define the server that will be receiving the sniffing information.  This is defined with this same command:
 
Controller# ap name <ap name> sniff dot11a <channel number> <ip address of server>
 
And/Or
 
Controller# ap name <ap name> sniff dot11b <channel number> <ip address of server>

BR,

Alex