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.

Nigel.

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):


BandChannelCentre
Freq
(Mhz)
UsageMax Power
With TPC
Max Power Without TPCDFS
A365180Indoor23dBm (200mW)23dBm (200mW)No
A405200Indoor23dBm
(200mW)
23dBm (200mW)No
A445220Indoor23dBm
(200mW)
23dBm (200mW)No
A485240Indoor23dBm
(200mW)
23dBm (200mW)No
A525260Indoor23dBm
(200mW)
20dBm (100mW)Yes
A565280Indoor23dBm
(200mW)
20dBm (100mW)Yes
A605300Indoor23dBm
(200mW)
20dBm (100mW)Yes
A645320Indoor23dBm
(200mW)
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: http://www.cwnp.com/cwnp_wifi_blog/fcc-laying-down-the-unii-law/).

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.

Nigel.

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:

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