Category Archives: Wireless

802.11 Duration/ID Field

I always knew that Duration/ID field is used by CSMA/CA to predict when wireless medium becomes free. However, I was confused by some publications which stated this field is set to the amount of time (in microseconds), required to transmit current frame, wait SIFS and then receive ACK. CWNA Sybex book has finally helped to understand this better.

Even though Duration/ID field tells STA how much time it has to wait before medium becomes free, it is set to the duration of SIFS + ACK. It doesn’t include the time required to transmit current frame. It kind of makes sense – to read the value from the field, STA needs to receive the frame in full and check its FCS before it can set the NAV with legitimate value.

Also, didn’t know ACK/Block ACK frames always have their Duration/ID field set to 0.

Again, makes sense. Transmission completed, all NAVs have to be reset to 0 – medium is ready for the next transmission.

Good to know: Historically this field was defined to identify STA’s association ID within PS-Poll frame (legacy power management) or Duration in any other frame. In reality, legacy power management is not being used and this field is mostly used as a Duration ONLY nowadays. However, name of the field is still Duration/ID.

ECSE Takeaways

Have just finished Ekahau Site Survey course in Oxford and here are my takeaways from it:

  • Move away from 2.4GHz completely (inc. BYOD and Guest networks if possible) – don’t use it in modern world
  • Avoid using multiple SSIDs – beacons make the air dirty (have captured 60MB of beacons on one channel in 15m as a test)
  • Don’t install APs in corridors or hallways – signal from omni antennas propagates on hundreds of meters in free space
  • Make sure signal strength from 2nd strongest APs meet the main requirements if voice roaming is of concern. This is an equivalent of Cisco’s channel overlap of 10-20-30% requirement, which is hard to measure or prove.
  • If APs are installed in rooms/offices, put them away from windows to avoid waste of RF energy sent towards the street.
  • Mirrors do not significantly affect 2.4GHz (and 5GHz) – waves are still lengthy enough to penetrate through mirrors (?).
  • Adjacent channels interference is more destructive than co-channel interference, because devices on adjacent channels do not play nicely when they access the media (do not contend)
  • Radio Tap header information is added by the client. RSSI and noise levels reported by clients are virtual and vendor specific. NICs do not see RF shapes to measure noise and RSSI, but spectrum analyzers do.
  • Ch144 on 5GHz was introduced with 802.11ac
  • ESS cheats
    • Don’t use small objects to define scale, such as doors, desks and so on. This increases error level.
    • Use distance between objects to define scale on one floor, then use alignment points to define scale on all others.
    • Use coverage and coverage exclusion areas to make ESS reporting more accurate (coverage percentage)
    • If floors are more or less identical, draw one and duplicate the rest (using image swap trick). This will help to save a lot of time as this trick copies all objects, including alignment points and scales.
  • Useful Tools
    • Buffalo WMR-433: Very tiny WiFi router which can reach out on tens of meters
    • Theodolite: iOS app to measure azimuth, elevation, GPS coordinates – helps with outdoor deployments
    • NetScout Link Sprinter 300: A link tester. Checks all layers of TCP/IP protocols suite (physical/data link, network, transport and application). Capable to send results by email.
    • HORST: linux-based lightweight 802.11 analyzer with text interface
    • Kismet: linux-based wireless sniffer/packet capture software

That was a great week in Oxford. Hopefully I haven’t misinterpreted the information above ūüôā

Cisco WLC SFP Inventory

We all know about very useful IOS command show inventory, which displays asset’s detailed information, including installed SFPs and their serial numbers. However, in case of AireOS, show inventory supplies very limited information – only chassis model and serial number, there’s no information about SFPs. Well, is there a way to find SFPs models and serial numbers? Yes, with the help of the following hidden AireOS command:

debug fastpath cfgtool --dump.sfp

Here’s an example output from one of ours WLCs:

(Cisco Controller)>FP0.
Port SFP Vendor       Transceiver Type    OUI PartNumber       Rev  SerialNumber     DateCode Auth
   1 CISCO-METHODE    (0x08)1000BaseTX        SP7041-R              MTC201XXXXX      16030701 ok
   2 CISCO-METHODE    (0x08)1000BaseTX        SP7041-R              MTC201XXXXX      16030701 ok

The model, the part and serial numbers are all there.

I hope you find this helpful.

Convert Lightweight AP into Autonomous AP

There are a number of ways to convert Lightweight AP into Autonomous. I personally prefer two.

First method is to use Console connection. It works very well, but of course requires a console, which in some cases can be troublesome¬†– i.e. someone¬†will have to arrange a PC connected to the network and console connection to the AP, which also has to be reachable from the PC once IP address is configured (i.e. L3 reachability). It also requires to press and hold Mode button before powering up an access point, which then has to be held up to 30 seconds until LED turns red. After that Mode button can be released and AP falls into rommon. Now, it’s just a matter of few commands:

tar -xtract tftp:// flash:

These commands assign IP address, netmask and default gateway to AP, initialize TFTP service and then download .tar archive with the image from TFTP server ( and extract its contents into flash. After this step is completed, AP can be either power cycled, or forced to boot with new image (using “boot” command). Also, I recommend to format flash before extracting new image ¬†using “format flash:“.

Works like a charm, but as I previously stated, requires a direct console connection.

Second method allows to downgrade Lightweight AP with Autonomous IOS without console access, but it requires AP to be accessible via SSH or Telnet. Once in AP’s CLI execute the following:

debug capwap console cli

This command enables full range of CLI commands, like config terminal, archive, or format flash (which by default are not available in LAP’s CLI). Therefore, it is now possible to do the following

archive download-sw /overwrite tftp://

Reboot and you’re on IOS code now.

Hope this helps.


Cisco Prime: Radiation Patterns and Antennas Orientation

Sorry for being silent for a while. I have moved to Leeds and now work in my company’s HQ as a project and design engineer. A massive change for me and my family. Anyway, this time I want to cover one very important topic – radiation patterns and antennas orientation in Cisco Prime (also applies to old buddy WCS).

If you have ever worked with Cisco Prime (or WCS) with regards to wireless networks management, you know how frustrating can be the process of adjusting access points’ radiation characteristics on the floor plan. Actually, it’s not a big deal if all access points have internal antennas and have been installed as per¬†Cisco’s recommendations. In such case, Cisco Prime applies default azimuth and elevation values to match best practice installation.¬†For example, omni-directional APs, like 1142N, 3602i or 3702i, have internal antennas and provide best coverage if installed¬†on the ceiling, facing down.¬†Of course, they can still provide optimal coverage in some scenarios with¬†wall mount installations, but in such cases a more proper planning is required. There is a high likelihood that access points from different floors will become adjacent in RF spectrum (i.e. will see each other) and it will be more complex for a controller to come up with optimal Tx power levels to meet coverage requirements. However, we all know that suboptimal installations happen in a real life. In such cases every access point has to be configured with custom azimuth and elevation values to help Cisco Prime to build correct heatmaps. This is especially important during the planning phase.

Note! In case of external antennas (i.e 3702e with patch or sectoral antenna), it is always required to adjust elevation and azimuth within Cisco Prime to let it know how antennas radiate on the floor plan Рnorth, south, west, east, north-west, south-east. This process can be even more complicated if antennas are installed at 45 (or custom) degrees to the floor/wall/ceiling. Continue reading

Cisco WLC 4400 Catastrophic Bug

I would like to make you all aware about catastrophic bug that affects (or may potentially affect) you. It applies to legacy eol/eos wireless controllers (Cisco WLC 4400 series), which are still massively deployed in many companies.¬†A friend of mine has asked me to help troubleshooting very strange problem they’ve been experiencing for some time.¬†Here’s a story and workaround. Continue reading

Finding Cisco Tx Power Levels

Tx Power Level is an important variable that, in combination with antenna gain, influences coverage patterns. Cisco wireless controller dynamically adjusts transmit power levels according to current RF conditions, access point’s capabilities and local regulatory domain recommendations, that may vary per band and/or channel. We, as an engineers, should be capable to confirm current Tx Power level, list of all supported Tx Power levels and antenna gain (if applicable). No coverage or heatmap approximations can be made without this information. With this post I will provide a number of different useful CLI commands that may be used to quickly find Tx Power levels information per-AP and in bulk. Continue reading

PoE-based access points Tx power level limitations

I recently noticed that Cisco AP 1142 Tx power level is not a constant value. It is dependent on a data rate in use.
Less words, here’s an example of “show controllers dot11Radio” taken from Cisco AIR-LAP1142N-E-K9:

interface Dot11Radio0
Radio AIR-AP1140G, Base Address b4a4.e3ca.f130, BBlock version 0.00, Software version 3.00.81
Serial number: <cut>
Number of supported simultaneous BSSID on Dot11Radio0: 16
Carrier Set: EMEA (EU) (-E)
Uniform Spreading Required: No
Configured Frequency: 2462 MHz Channel 11
Allowed Frequencies: 2412(1) 2417(2) 2422(3) 2427(4) 2432(5) 2437(6) 2442(7) 2447(8) 2452(9) 2457(10) 2462(11) 2467(12) 2472(13)
Listen Frequencies: 2412(1) 2417(2) 2422(3) 2427(4) 2432(5) 2437(6) 2442(7) 2447(8) 2452(9) 2457(10) 2462(11) 2467(12) 2472(13) 2484(14)
Beacon Flags: 0, Interface Flags 20105, Interface Events 0, Mode 9; Beacons are enabled; Probes are enabled
Configured Power: 17 dBm (level 1)
Active power levels by rate
1.0 to 11.0 , 16 dBm, changed due to regulatory maximum
6.0 to 48.0 , 13 dBm, changed due to regulatory maximum
54.0 to 54.0 , 11 dBm, changed due to regulatory maximum
6.0-bf to 54.0-b, 10 dBm, changed due to regulatory maximum
m0. to m5. , 13 dBm, changed due to regulatory maximum
m6. to m6. , 11 dBm, changed due to regulatory maximum
m7. to m7. , 10 dBm, changed due to regulatory maximum
m8. to m13. , 13 dBm, changed due to regulatory maximum
m14. to m14. , 11 dBm, changed due to regulatory maximum
m15. to m15. , 10 dBm, changed due to regulatory maximum
m0.-4 to m5.-4 , 13 dBm, changed due to regulatory maximum
m6.-4 to m6.-4 , 11 dBm, changed due to regulatory maximum
m7.-4 to m7.-4 , 10 dBm, changed due to regulatory maximum
m8.-4 to m13.-4, 13 dBm, changed due to regulatory maximum
m14.-4 to m14.-4, 11 dBm, changed due to regulatory maximum
m15.-4 to m15.-4, 10 dBm, changed due to regulatory maximum
6.0-d to 48.0-d, 13 dBm, changed due to regulatory maximum
54.0-d to 54.0-d, 11 dBm, changed due to regulatory maximum
OffChnl Power: 16, Rate 1.0
Allowed Power Levels: -1 2 5 8 11 14 17
Allowed Client Power Levels: 2 5 8 11 14 17

Why is it like this? Why higher data rates have lower Tx power levels? These were my questions too. Continue reading

Access Points migration to vWLC. Tips and Tricks.

We recently begun to massively replace our end-of-life Cisco Wireless Controllers 4400 series with ESX-based Cisco Virtual Wireless Controllers (vWLC). The deployment process is straight-forward and well documented by Cisco in “Cisco Virtual Wireless Controller Deployment Guide“. We haven’t had any major issues with the deployment, but we faced some problems when it came to the migration process of the existing AP infrastructure to these new controllers. While current AP models (2600/3600) can join vWLC with no hassle, old, but still decent, AP models (like Cisco 1140 series) require some extra efforts before they can join vWLC… Continue reading