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