Cisco WLC: Per-client Packet Capture

-

Sometimes, you just want to capture the packets associated with a particular wireless client and see what the heck is going on with that client. Often, it may not be practical to do an over-the-air packet capture, as perhaps the client is at a remote location or just just don't have access to a wireless capture card.


I recently had an issue trying to understand why an Android device that I was trying to 'on-board' using Cisco's ISE wouldn't access the Google Play store. I desperately wanted to capture the over-the-air frames from the client to have a look at what the client was doing.


After a quick 'Google' around, I found an intriguing set of Cisco WLC CLI commands that allow a packet capture of traffic for a wireless client. This can all be done without having to change the AP mode, or reboot the AP etc.
In summary, the feature allows packets to be captured for a specified wireless client that is sending/receiving traffic to/from an AP. The AP will continue to process all user traffic as per usual, with the target client frames being streamed to an FTP server for a specified period. The resultant capture file is in standard pcap format that can be opened with Wireshark (amongst others).

The feature looks like it became available from WLC code 7.4 - full details can be found at the following URL : http://bit.ly/wlc-pkt-capture

In summary, the following work-flow worked pretty well for me:

  1. Identify the client MAC address you would like to capture
  2. Identify the FTP server to receive the trace file:

    config ap packet-dump ftp serverip <ip-address> path <path> username <user_ID> password <password>
  3. Configure the frames to be captured - data frames worked well for me:

    config ap packet-dump classifier data enable

    (don't try to capture without specifying a classifier, as you capture nothing - I tried it...)
  4. Start the client packet capture for the target client:

    config ap packet-dump start <client-mac-address>
  5. After a while, you can stop the capture sessions and see what you've got: (note that by default, the capture session stops after 10 mins)

    config ap packet-dump stop

    (note that the FTP server may not show any frames captured until you stop the capture and it empties out its buffer)

There are a few caveats to this capture technique, but it is still a very powerful tool to add to your WiFi utility belt. Caveats include:

  • beacons and probe responses are not captured
  • the client must be associated with an AP joined to the WLC
  • only frames for one client at a time can be captured
  • does not work from inter-controller roaming

Here are all of the commands for your reference (taken from the Cisco configuration guide):

  • Configure FTP parameters for packet capture by entering this command:

    config ap packet-dump ftp serverip ip-address path path username user_ID password password
  • Start or stop packet capture by entering this command:

    config ap packet-dump {start client-mac-address ap-name | stop}
  • Configure the buffer size for packet capture by entering this command:

    config ap packet-dump buffer-size size-in-kb
  • Configure the time for packet capture by entering this command:

    config ap packet-dump capture-time time-in-minutes

    (The valid range is between 1 to 60 minutes.)
  • Configure the types of packets to be captured by entering this command:

    config ap packet-dump classifier {arp | broadcast | control | data | dot1x | iapp | ip | management | multicast | {tcp port port-number} | {udp port port-number}} {enable | disable}
  • Configure the packet length after truncation by entering this command:

    config ap packet-dump truncate length-in-bytes
  • Know the status of packet capture by entering this command:

    show ap packet-dump status
  • Configure debugging of packet capture by entering this command:

    debug ap packet-dump {enable | disable}

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more