Saturday, 24 November 2012

Useful Win 7 Command for Wireless

This probably falls into that category: "stuff that everyone else already knows, but I don't", but I thought it was worth jotting down a few notes about.

I recently saw someone tweet about the command: "netsh show wlan <various options>", which I had never heard of before.

After having had a look through the command help screens, it seems an incredibly useful command if you want to quickly find out about the wireless networks and the wireless capabilities of a Windows 7 machine you're working on. Much of the information can be found by poking around in various GUI pages, but this command line utility is much quicker to use and gives a greater depth of information.

I'll just run through a few useful examples and then leave you to poke about in the help pages yourself if you want to know more.

A great way to get a summary of the wireless networks that a Win 7 client can hear is to open a command window (...or a DOS box as I like to call it) and enter the command: "netsh show wlan networks":

On the face of it, this maybe isn't massively impressive, but if you add the command switch "mode=BSSID", things get a little more interesting:

You now get to see some great information which includes authentication and encryption types, radio type (802.11g/n/a etc.) and channel. Very useful information.

 The final command variation I'll look at is: "netsh wlan show drivers". This command shows you extensive information about the radio types and authentication and encryption types supported by your wireless driver. I'm guessing that I need to caveat this by saying that there may be some hardware and even OS dependencies that need to be fulfilled for the client to actually support all of these:

Finally, there are plenty more options to play with, so have a poke about in the help screens and see if there are more useful nuggets you can find :) Here is the help screen output to whet your appetite:

(Update: I have been advised by a couple of very reliable people that this command also works on Windows 8)

Friday, 23 November 2012

Your system does not support long mode

Just a quick note for anyone who may come across a similar issue when trying to deploy server images on to their VMWare environment.

I've been lucky enough to get a new server recently to test various virtual WLCs and management packages that are being put out by various wireless vendors. But after installing ESXi and deploying a couple of server images, when I tried to start the virtual servers up, I kept getting the following messages popping up in vShere:

(For search engine benefit: This virtual machine is configured for 64-bit operating systems. However, 64-bit operation is not possible. Longmode is not possible. Longmode is disabled for this virtual machine)

Also, in the console of the server (Cisco MSE & NCS), I was getting the following reported: "Your CPU does not support long mode. use a 32 bit distribution"

I was concerned that maybe there was an issue with my server CPU, in terms of support for virtualization. 

I rebooted the server and dropped in to the BIOS setup and found that the virtualization parameter for the processor settings was set to disabled! So, I enabled it and rebooted. But, the issue persisted :(

So, I dropped in to the BIOS setup again and noticed a little note that said that a complete power-off was required once the virtualization setting had been changed.

A few minutes later, after a complete power off, my virtual servers were finally booting correctly!

Probably a complete noobie error, but we've all got to start somewhere :)

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:

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)

Monday, 8 October 2012

The Missing Channels on 5GHz in the UK : 120, 124, 128

In my recent article : 'WiFi Channels On The 5GHz Band In The UK', I noted that although the 5GHz channels 120, 124 and 128 are unlicensed channels available for use by WiFi equipment in the UK, it appears that a few major WiFi equipment manufacturers do not allow their use (in the UK or EU).

I spoke with a major vendor representative today who advised me that the 3 channels are available for use, but that an update to the ETSI standard 301 893 v1.5.1 introduced some detection techniques for various military equipment used in the EU. However, many access points that were already manufactured (or using chip-sets that had already been manufactured) did not support the granularity of detection that is required for this equipment. So, it was decided to simply disable support for the affected channels.

Apparently, later APs which use an updated chip-set will not be subject to the same limitations (once a few firmware updates are sorted out).

I had a poke about in the standard to see if I could track down the offending addition, but there didn't seem to be a "what's new" or "change log" that accompanies the document. All I could find was the following note in the ETSI work program item that accompanies the standard:

"Include Staggered PRF radar test signals across the 5 250 MHz to 5 725 MHz band. Include narrow pulse widths for the radar test signals (0,8 ┬Ás) across the 5 250 MHz to 5 725 MHz band. Address noise calibration scan ("zero check") in the 5 600 MHz to 5 650 MHz band."

Perhaps the "zero check" scan that is referenced is the offending item that caused the issue - it certainly falls within the range of the channels that have been disabled.

Although this doesn't provide a comprehensive answer, it at least suggests why we have lost a few channels on 5GHz here in the EU (at least for the moment, anyhow).

UPDATE: I now have an answer on this! Check out my later article here.

Update: I've now created a white paper which details 5GHz usage for WiFi in the UK. Find it here

Sunday, 23 September 2012

Which 5GHz Channels Does My Device Support?

I've been on a bit of a 5GHz quest recently, trying to get to grips with all of the nuances of supporting WiFi devices on this rather (in my mind) troubling band.

Until fairly recently, it seems that the default band of choice for many WiFi devices has been 2.4GHz (802.11g/n). But as the whole 'bring your own device' area has exploded, networks require more high-density deployments, 802.11ac is on the horizon and consumer grade devices are starting to support 5GHz in increasing numbers, it looks like 5GHz is going to transition to being the band of choice over the next year or two.

However, there seem to be a number of considerations that need to be taken in to account when delving in to the 5GHz 'wonderland'. There are far more non-overlapping channels available (19 in the UK) compared to 2.4GHz (generally 3 channels), which is going to potentially deliver much better performance gains (with the mitigation of co-channel interference, lower noise floor etc.). However,  terms such as 'DFS' and' TPC' start to crop-up and a myriad of channel usage restrictions across the band need to be understood (e.g. indoor/outdoor use, varying power levels, varying DFS support etc.).

As if this isn't enough, I was recently warned of the dangers of ensuring that client devices support all of the 5GHz channels that you intend to use. I must admit that my assumption (until recently) was that if a device supports 802.11a/n, then it will support all of the channels that are dictated by the local  regulatory authority (e,g, FCC, ETSI etc.). But, apparently not...

I'm not sure how extensive the lack of support for all available 5GHz channels is among 802.11a/n devices, but it is certainly a consideration when designing WiFi networks that use the 5GHz band (I am reliably informed). I'd be interested to know if this issue is only applicable to older devices, or is due to device assumptions about their regulatory domain - drop me a comment with your experiences/knowledge!

I fired up a couple of devices to check their support for 5GHz channels as a bit of an experiment. I have an iPad 2 and a Galaxy S3 phone, which both support 5GHz.

My initial thought was to fire up my test AP on channel 36 and test both devices to verify they can associate to a test SSID. Then I would move on to channel 40 and check again. Checking each of the channels supported in my particular part of the world, I could verify if all channels are in fact supported by both devices.

However, I had a WiFi analyzer to hand and was capturing a few frames to see what was going on during my testing. Luckily, I spotted some capability fields in the association request of each device which really helped me out. In the association frame there are 'supported channels' fields that show which 5GHz channels the client device supports. This is exactly the information I needed to know!

I've posted a couple of screen shots below to show what I saw using a WiFi analyzer:

Fig. 1 - iPad 2 Association Frame

Fig. 2 - S3 Association Frame
In each association request, you can see the supported channels for the client device. It's a bit tricky to read on first glance, but if you look carefully, you can see the start of a channel range (called 'First Channel') followed by the number of channels in that range.

Looking at the iPad frame, we have channels 36, 40, 44, 48 (first channel - 36, num of channels = 4), followed by channels 52, 56, 60, 64 (first channel - 52, num of channels = 4), followed by 15 other channels (see frame detail). This gives the full 23 channels you might expect in the USA, but is actually more than we can support here in the UK!

The S3 supports just the 19 channels we have available here in the UK. I'm guessing this is because it is manufactured specifically for Europe.

Looking at these frame captures, we shouldn't have any issues using these here in the UK, using all 19 channels we have over here on 5GHz, if we wanted to use them.

It's certainly worth checking your devices when planning to use them on a 5GHz WLAN, just to be sure you don't have clients that  only work on a subset of the channels you intend to use on your WLAN (which could obviously cause connectivity issues to some clients).

If you don't have a wireless analyzer to do this investigation, it might be worth checking out running Wireshark on Linux. You can sometimes find a wireless NIC card that will run with a Linux distribution in a promiscuous mode, so that it can capture frames. I recently downloaded the latest copy of the Backtrack distribution (the penetration toolkit) and found that the built-in wireless NIC in my Dell laptop is now supported (a nice surprise!). I can run the Backtrack distribution by booting from a USB stick and use it as a great wireless analyzer (Wireshark is part of the distribution) - I don't have to disturb the main OS on my laptop at all.

Anyhow, as I said, I'd be interested to hear of other folks experiences with client support on 5GHz. Drop me a comment if you can.


Related Post: Which iPads Are on the Network?

WiFi Channels On The 5GHz Band In The UK

(Note: I now have a whitepaper on this topic you may find useful: link)

One of the issues of not being in the 'good ole U S of A' is that most of the study and reference literature that is available around WiFi is USA-centric.

This means that when you are trying to get your head around the various spectrum restrictions that apply to the unlicensed 5GHz band that is used by 802.11a/n, there is little off-the-shelf material that applies to regulatory domains  outside of the USA.

Most material that can be found online tends to advise the reader to check the restrictions of their own regulatory domain and any local country restrictions that apply. This is actually a bit trickier than it sounds (in my experience).

I'm based in the UK and recently decide to embark on a quest to find the actual source regulations that apply to the use of the 5Ghz band by (unlicensed) WiFi equipment.

Although they are a little thin on the ground, I managed to find a couple of very good articles which talk about the use of 5Ghz in the UK. You can take a look at them here:

Although the articles are very good, I was keen to find the source materials for the regulations governing 5GHz use (for unlicensed WiFi) in the UK.

After some digging around, I finally found that the use of RF spectrum in the UK is dictated by an independent regulator called Ofcom. They have a number of documents called 'Interface Requirements' which spell out the various regulations that have to be adhered to for various parts of the RF spectrum.

The document covering the use of 5GHz 'RLANs' (that is Ofcom parlance for WLANs) is titled: IR 2006 - Wireless Access Systems (WAS) including RLANs operating in the 5150-5725 MHz band.

In this document, it spells out (in summary) that the UK's (unlicensed) 5GHz band is broken up in to 2 bands:

  • Band A : 5150 - 5350 MHz (channels 36 - 64)
  • Band B: 5470 - 5725 MHz (channels 100 - 140)
Band A channels can only be used indoors. Band B channels may be used indoors or outdoors and may be used at slightly higher power levels if required.

However, the IR 2006 document also refers to an ETSI document for further clarification around the use of the 5GHz band, particularly if you're interested in areas such as TPC and DFS. This document has the rather dry title of :

Broadband Radio Access Networks (BRAN); 5 GHz high performance RLAN; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive

This document also has the rather snappy designation of : ETSI EN 301 893 V1.7.1 (2012-06). (Note there are several versions of this document floating around from previous incarnations, but I'm pretty sure v1.7.1 is the current (at the time of writing) ratified document).

My main interest in reading the ETSI document was to try to understand which channels are subject to DFS, as this is going to be an interesting area in the near future with the anticipated significant rise in uptake of WiFi kit on 5GHz. I have read varying reports on which channels are subject to DFS in the UK  and wanted to find a definitive document which details DFS restrictions in the UK.

If I have read the document correctly (and it is quite a hefty tome to get to grips with), it looks like channels 36 to 48 are not subject to DFS in the UK, but all other channels are required to implement DFS safeguards. This was quite a surprise, as I had previously believed that channels 36 - 64 were not subject to DFS (as they are designated for indoor use), with all remaining (outdoor) channels being subject to DFS.

I spent quite a while looking at both of the documents discussed above and came up with the following tabulated data, after cross referencing them both. (Disclaimer - check the current versions of the documents from both Ofcom & ETSI - things may have changed since I wrote this):

UsageMax Power
With TPC
Max Power Without TPCDFS
A365180Indoor23dBm (200mW)23dBm (200mW)No
23dBm (200mW)No
23dBm (200mW)No
23dBm (200mW)No
20dBm (100mW)Yes
20dBm (100mW)Yes
20dBm (100mW)Yes
20dBm (100mW)Yes
B1005500Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1045520Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1085540Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1125560Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1165580Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1205600Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1245620Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1285640Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1325660Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1365680Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes
B1405700Indoor/Outdoor30dBm (1W)27dBm (500mW)Yes

In summary, this appears to give us 19 channels to use on the 5GHz band in the UK for unlicensed WiFi.

Unfortunately, there seems to be a trend among some access point vendors to not support channels 120 - 128. I can't find any Ofcom or ETSI regulations that apply to this, but it may be due to some FCC regulations which have perhaps found their way in to vendor implementations for those of us in the rest of the world (see this article:

So, for whatever reason, it looks like many vendors have restricted us to 16 x 5GHz channels, which is still a nice large number to play with, but with the advent of increased-width bonded channels in the forthcoming 802.11ac standard, I think we're going to miss those extra channels.

One other area I'm intrigued by is definitions around the terms 'indoor' or 'outdoor' use. With the rise in WiFi deployments in sports arena, temporary venues etc. the lines between indoor and outdoor become a little blurred. For instance, is a temporary marquee with an AP installed outdoors? What about a football stadium? What about a stadium with a roof? If anyone has any official definitions for indoor and outdoor form a WiFi standards or regulatory RF point of view, I'd be interested to hear them.

Hopefully, this article may be of interest to those trying to find out more about 5GHz WiFi in the UK (and perhaps Europe), even if it only points you in the right direction to find your own information - I'm sure there are going to be many more conversations and queries raised around 5GHz its popularity increases as more consumer devices gain 5GHz support.

If you have feedback or additional information about this topic, please feel free to post updates, corrections and comments - I don't claim to be an authoritative resource on this topic, so please feel free to correct me if required.


Update: I've now created a white paper which details 5GHz usage for WiFi in the UK. Find it here

Tuesday, 18 September 2012

Installing a PFX File on a Cisco WLC

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:

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 up with a resultant certificate file in the required file format to import into your WLC.

I had an instance recently where a customer had generated a certificate using their usual CSR method (I’m not too sure what they used), but the resulting file they received from their public CA (Thawte in this case) was a ‘.pfx’ file (Personal Information Exchange). The file required to import in to a WLC is a ‘.pem’ file (see this page for more information about various certificate file formats)

So, I was a in a bit of a tight spot, as the supplied ‘.pfx’ file was the incorrect format. I tried (in desperation) to import it anyhow, but it just failed with a rather unhelpful ‘file transfer error’ message.

So I had a dig about on the Internet and found a very useful document which walked through the process of how to convert the pfx file into a format I could use to create my final pem file.

To convert from pfx to pem format, I still needed the services of Open SSL, which I installed onto my Windows 7 laptop. You can get it from this page, but make sure you get the 0.9.8 version, otherwise the resultant files will not work on a Cisco WLC (you have been warned). Also, I believe that this process can only be performed if the pfx file you have been supplied with allows the export of the private key (this would have been specified as part of the certificate request). You will also need to know the import password for the certificate, which will have been specified when creating the original CSR.

There are 2 stages to the process:

  1. Extract and verify various elements from the pfx file
  2. Completion of the process described in the original Cisco configuration document to generate the final ‘.pem’ file

Stage 1

First of all, we need to extract various elements and verify checksums of what we have extracted. In the examples shown below, I have used the prefix ‘Wireless_Cert’ so indicate the various input and output files used.

The starting point is an input file called : Wireless_Cert.pfx. Inline comments indicate what each step is achieving.

The commands run below are run from a standard DOS command line and assume that openssl is in your %PATH% variable (set path=%path%;C:\OpenSSL\bin;). All operations will be performed in the c:\temp directory in this example. (Note: all commands will be on a single line, not broken by line-wraps)

  • Export the private key (import password for certificate required) - creates a new file: Wireless_Cert.key:openssl pkcs12 -in c:\temp\Wireless_Cert.pfx -out c:\temp\Wireless_Cert.key -nocerts -nodes
  • Remove the private key encryption - creates a new file: Wireless_Cert_s.key:openssl rsa -in c:\temp\Wireless_Cert.key -out c:\temp\Wireless_Cert_s.key
  • Export the SSL certificate (import password for certificate required) - creates a new file: Wireless_Cert.pem
    openssl pkcs12 -in c:\temp\Wireless_Cert.pfx -out c:\temp\Wireless_Cert.pem -nokeys -clcerts
  • Run the following commands. They should produce the same checksum if all has gone well:openssl x509 -noout -modulus -in c:\temp\Wireless_Cert.pem | openssl md5
    openssl rsa -noout -modulus -in c:\temp\Wireless_Cert_s.key  | openssl md5

You will now have a file called : c:\temp\Wireless_Cert.pem which will be the subject of stage 2 of our process.

Stage 2

In this stage, we combine the pem file from stage one with the (unencrypted) key file to create our final pem file.

Following on from our previous conventions, execute the following commands from a DOS command line. Note that the import password from the previous stage is required and embedded in the commands below, indicated by ‘xxxxxx’ :

  • Combine the .pem file and key file - a new file is created : c:\temp\All-certs.p12

    openssl pkcs12 -export -in c:\temp\Wireless_Cert.pem -inkey c:\temp\Wireless_Cert_s.key -out c:\temp\All-certs.p12 -clcerts -passin pass:xxxxxx -passout pass:xxxxxx
  • Create the final pem file: c:\temp\final-cert.pem
    openssl pkcs12 -in c:\temp\All-certs.p12 -out c:\temp\final-cert.pem -passin pass:xxxxxx -passout pass:xxxxxx

The final file that is created is: c:\temp\final-cert.pem, which is the file imported in to the WLC, as described in the original Cisco configuration document

Don’t forget that all of the steps described above can be found in the following couple of documents, if you should need them for reference:

Monday, 25 June 2012

Disabling the LED Indicator on a Cisco Lightweight AP

This is just another one of those ad-hoc posts for a piece of information I get tired of looking up.

I often get the question: "can I disable the LED indicator on a Cisco Lightweight Access Point?". At this point, I always have to jump for my CLI reference guide and can never remember the right word to search for.

So, here is the command I need (for next time...):

config ap led-state  {enable |  disable} {cisco_ap  |  all} 

It can only be done from the CLI as far as I am aware.

It can be useful from time to time if you have someone in a dark room who is annoyed by the lamp, or even more useful, if you are trying to track a particular AP that perhaps you aren't too sure of the location of ("go and look for the AP with no lamp on").

I just hope I remember that I blogged about this next time I need this command...

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, 14 June 2012

One User, Many Devices

I've been read lots recently about BYOD and how many users in an organisation may well have 2, 3, 4 or more devices that they wish to use on a WiFi network. The will often have a laptop, possibly a tablet and almost certainly some type of smartphone.

The characteristics of these different types of device vary enormously, depending on the device capabilities and their RF characteristics.

I thought it might be interesting to just fire up 4 random devices I have in my home and compare the signal levels I could see from the same SSID on my home ADSL router. Each device had some type of software installed that could (allegedly) report the signal level that the AP is observed at from the client device point of view.

I know this isn't a particularly definitive approach, as the software used probably has varying levels of accuracy, so I wouldn't treat these results as being too accurate. But, they may give an indication of different device performance.

The devices I tested were:

  • Samsung GT-S5570 (Android Version 2.2.1) - smartphone
  • iPad2 (IOS 5.0.1) - tablet
  • iPod Touch 3rd Generation (IOS 5.1) - tablet...well, sort of
  • Dell Latitude E6420 (Intel(R) Centrino(R) Ultimate-N 6300 AGN) - laptop
The graphical results are shown in the screen shots below. The SSID used in each case was 'CiscoNet' (it's an ironic SSID, as the ADSL router used isn't a Cisco device...):

Samsung GT-S5570

iPad 2


Dell Laptop

The results, if accurate were pretty much what I expected. The laptop RSSI was the highest, averaging around the -60 to -63dBm level, with the iPad coming in second (varying quite a bit, but lets call it an average of -70dBm). The iPod was third around the -75dBm level, with the Samsung smartphone coming in a miserable fourth at around -82dBm.

This certainly shows the value of surveying with a device similar in characteristics to the actual device that will be used on the network. Just relying on a laptop survey on this network may have left things sadly lacking for smartphone users who were hoping for a a good WiFi connection. :)

Tuesday, 24 April 2012

Decoding Cisco CAPWAP With Wireshark

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. You can it in the find the options panel at : Edit > Preferences > Protocols in the Wireshark GUI.

Select the CAPWAP protocol and check the 'Cisco Wireless Controller Support' check-box and everything decodes as you would expect :)

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