Showing posts with label WLC. Show all posts
Showing posts with label WLC. Show all posts

Tuesday, 12 August 2014

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}

Wednesday, 21 November 2012

Cisco DTLS License

The whole area around the free DTLS license that can be obtained for Cisco WLCs has always been a bit of a head-scratcher for me.

I'm never sure whether I need the additional license or I already have it to be honest. Anyhow, today on my home lab I tried to have a look at some features which required DTLS between the AP & WLC, only to find that my 2504 did not support the option (the option was grayed out).

After some digging around on the Cisco forums, I found that the following licensing link can be used to obtain the DTLS entitlement license with very little fuss at all:

https://tools.cisco.com/SWIFT/LicensingUI/loadDemoLicensee?FormId=4090

The information to be entered can be found on the WLC inventory page. Only the model number & serial number are required.

Within seconds, I had the license (which can be downloaded directly or sent by email) and applied it to my 2504 (Management > Software Activation > Commands > Install License)

Friday, 15 June 2012

Issue: Having to log back in on Apple devices on a Cisco wireless guest network

I'm documenting this for my own reference as much as anything, to avoid having to look this information up (yet again).

(This description assumes that the use-case is for a guest network, but will apply to any layer-3 authenticated wireless network)

It is a common occurrence on Cisco wireless networks (using a WLC of some type) to have complaints from guest users that they have to keep logging back in to the guest network after their device has gone in to sleep mode. They are often put in to sleep when they are enveloped in some type of holder or covering system that has a built-in magnet to make them sleep when they are not in use (this is very typical on iPad holders/covers).

The reason for the annoying issue of having to log back in to the guest network is that the WLC has a user idle timeout setting which expires (by default) after 5 minutes. So, when a device is put in to sleep mode, the WLC will not hear from it for a while and then after  5 minutes will terminate its session.

If you know a little about WLCs, you would expect this behaviour to be dictated by the 'session timeout' setting which is available on the WLC GUI via the Advanced tab of the WLAN definition. But, that timer is the time-out for the entire (continuous) session. If you wish guest sessions to automatically end after a pre-defined period of use (e.g. force guest users to re-authenticate every couple of hours of use), you would use that setting.

To configure the idle time-out setting, you can only configure this via the CLI (in version 7.0 code anyhow) using the command below. Remember, this is the setting that will determine how long a client is idle (e.g. in sleep mode)  before its session is terminated. The command to use is:

config network usertimeout  seconds

The 'seconds' value is obviously the amount of time a device can be idle before its session is terminated. By default, it is 5 minutes (300 seconds), and can be a minimum value of 90 seconds.

The value you choose depends on how long your users may put their device to sleep for. Obviously you need to wind it up above the default of 300 seconds if users are complaining. I'd suggest trying 15 minutes (900 secs) and maybe wind it up  if users still complain (...try 30 minutes(1800 secs) next?).

The only downside to winding this value up is that clients will sit in your client list on the WLC for longer. Normally, they would time-out within 5 minutes. But, if you wind this value up, they won't age-out as quickly.

Right...the next time I need this info, I know exactly where to find it.

(Note: I had a note via Twitter from @revolutionwifi advising that another consideration with this approach is the possible impact this may have on WLC memory, which is a fair point. I guess it depends very much on your environment. This setting is going to affect all clients that attach to the WLC, so if you have large numbers of users, you may need to keep an eye on your memory usage. I suspect this would only be an issue if you had an environment where you have many unique users who come and go during the day, who would effectively hang around in the WLC memory for longer periods than you would like.)

Thursday, 19 April 2012

Fast SSID Change - Out Of The Shadows

There are many configuration settings on a piece of networking kit that are just 'there'.

They sit there year after year just minding their own business being a quiet little chunk of configuration sitting in their default state not doing anyone any particular harm. Then, occaisionally, you come across some obscure case that causes you to actually pay attention to what exactly that particular setting is 'bringing to the party'.

One particular instance I came across recently is the 'Fast SSID Change' setting on a Cisco WLC.

From memory, it's been sat there for quite a while on many of the controllers I've installed, sitting dutifully in its default state of 'Disabled'. I've never really paid it much attention as it doesn't (on the face of it) seem to cause anyone any particular problems.

However, I recently ran in to a situation where a customer had some Apple iPads that he wanted to connect to an SSID that was mapped to an internal corporate VLAN. The iPads connected up quite nicely using PEAP - nothing too interesting there. However, the customer also wanted to flip an iPad or two across to the guest user SSID, which was mapped on to a completely different VLAN and anchored to a DMZ controller. The reason to flip between the 2 SSIDs was purely to carry out testing of the new wireless solution (i.e. corporate users with iPads and guest users with iPads).

The iPad was correctly configured for both SSIDs. To flip between the 2 SSIDs, we simply opened the network settings of the iPad and selected each SSID in the list of shown wireless networks. (For full disclosure, the iPad was running iOS 5.1.x, the guest SSID was brodcasting and the corporate SSID was set to not broadcast).

However, when I tried to flip between the SSIDs (e.g. guest SSID to corporate SSID), the iPad would attempt to connect to the newly selected SSID, but would fail and fall back to the original SSID that it was connected to. The real head-scratcher was that a smartphone correctly configured for both SSIDs switched between the two SSIDs back and forth with no issues at all!

After quite a bit of pondering and double-checking of the iPad wireless configuration, I decided to run a client debug on the WLC. The debug seemed to show that the iPad was associating with the newly selected SSID, but then reverted back to the original SSID before any authentication took place. I wasn't too sure what was going on...

After some digging around, I found a few Cisco forum posts talking about 'Fast SSID Change' which sounded like it might be related. Here is the description of the 'Fast SSID Change' parameter from the WLC help files:

"When you enable Fast SSID Change, the controller allows clients to move between SSIDs. When the client sends a new association request for a different SSID, the client entry in the controller connection table is cleared before the client is added to the new SSID.


When Fast SSID Change is disabled, the controller enforces a delay before clients are allowed to move to a new SSID."

So, I tried changing the 'Fast SSID Change' parameter to 'enabled' and suddenly the iPads were happily switching between the two SSIDs with no issues!

I'm guessing this was a timing issue on the iPads - I guess they weren't quite as patient as the smartphone.

The question remaining in my mind is this: why is 'Fast SSID Change' set to disabled by default? I wonder if there are any particular reasons you wouldn't want to just blindly enable it for every installation of a new WLC? (I haven't found any reasons to date...)

I tried to think of other scenarios where you may run in to this issue. It's hard to think of any beyond the testing scenario I described above, but I guess there will be one or two use-cases. I thought of something perhaps around a provisioning-type WLAN where maybe some type of client or agent is provisioned to an iPad and then you need to flip across to another SSID to use the new client or agent, but that was the best I could come up with.

I'd be interested to hear if anyone else has any good arguments for or against enabling 'Fast SSID Change'.

References: