WifiNigel

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. T...

If you're using an authentication server (such as Cisco's ACS) to make policy decisions about wireless users, there may be times when you'd like to make a decision based on the name of the SSID that the user is joining. In this article, we'll look at how you can do this. In this article, I'm going to assuming that we are using a Cisco wireless LAN controller, together with a flavour of Cisco ACS 5.x. I've seen this method used with Cisco ACS 4.x (see references at the bottom of this article) and wouldn't be surprised if you could modify the technique for other RADIUS servers. When Googling about this subject, I don't see any results that show how to do this in ACS 5.x, so thought it was worth a quick note. Background In brief, when a wireless client is attempting to authenticate to an SSID on a Cisco WLC network, if 802.1x is being used to authenticate users, then various RADIUS attributes are sent to the RADIUS server (e.g. ACS) as part of ...

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)

Cisco provide an excellent guide on how to create a CSR for a wireless LAN controller so that a certificate signed by a public CA can be installed. This is often very useful if you are using the WLC as a guest controller and want to prevent browser security messages that pop-up in a guest’s browser each time they access your guest wireless network. The Cisco guide can be found here: http://www.cisco.com/en/US/customer/products/ps6366/products_configuration_example09186a0080a77592.shtml It also details how to install the chained certificate (provided by a public CA) on to the WLC. The certificate in the examples shown in the document use a ‘.pem’’ (Privacy Enhanced Mail) format file. The method described in the (Cisco) document involves generating a CSR using Open SSL version 0.9.8 to create a certificate request which is then submitted to a public CA such as Thawte, Verisign etc. It should be  possible to generate CSRs using other methods (other than Open SSL), but you may not end ...

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 termi...

Here's an interesting little gotcha I wasted a few hours on recently... I have been looking at QOS on a Cisco WLC and was looking at DSCP markings in CAPWAP packets between a Cisco WLC and access point. I did this by spanning the switch port that the AP is connected to and then using a copy of Wireshark on another switch port to capture the traffic so that I could have a look through it. However, when I looked at the CAPWAP frames, Wireshark was reporting most of the CAPWAP packets as being "Association Requests" and that they were "[Malformed Packets]". After testing this in quite a number of versions of Wireshark (assuming a Wireshark decode bug), I finally gave up and reported a bug to the guys at Wireshark. They were incredibly quick to respond and diagnosed the issue very quickly! It turns out that Cisco have not implemented the final draft of CAPWAP (according the guys at Wireshark), and that there is an option in Wireshark for Cisco CAPWAP support...

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...

If you're like me, then when it's time to use or install a new release of software, you quickly scan through the release notes trying to make sense of the reams and reams of 'new features', 'caveats', 'bugs fixed' etc. without falling to sleep and smashing your nose on the desk in front of you. (Why can't technical writers give those things a plot, a love interest and a gripping ending..?) The main purpose of this exercise is often to pick up the 'headlines' so that you can fairly comfortably install or implement the new software, armed with a reasonable amount of knowledge to allow you to not fall down any particularly large holes during the process. One area I'm particularly guilty of 'glossing over' in this release-note-scanning activity is the section that describes the versions of browser support that are provided for web-GUI based products (e.g. network management software). Sure, I give the browser support section a ...

Overview Before the advent of WLC code version 7.0.116.0, it was difficult to scale a Cisco guest wireless solution (in terms of IP address space) due to the fact that all foreign controllers (i.e. non-guest controllers) could only map to a single layer 3 interface on the guest (anchor) controller. This often meant that a very large subnet had to be allocated to guest users to allow for multiple sites which shared a guest controller. The guest controller is usually located on a firewall DMZ interface (perhaps in a data center). The only way around this was to have multiple guest SSIDs (e.g. one per building), with a separate VLAN for each SSID. This is not a very popular option with customers as there is no consistency of SSIDs between sites/buildings. Another drawback of the single guest-VLAN restriction is that all guest traffic originates from a single subnet range. From an administrative point of view, it is often desirable for guest traffic from different buildings or sites ...