WifiNigel

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

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

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)

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

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

( Note : This information has been superseded (and is out of date!) I now have a whitepaper on this topic you should use instead: 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 l...

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

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

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

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

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