WLC and AP Power settings

AP Power settings made easy

To fully understand and sometimes troubleshoot our wireless networks, we need to know exactly what is going on with our AP s, especially what power they are outputting. So in this post we are going to look at AP Power settings made easy.

A man is drawing a diagram of an internet network

The Problem – Different AP models each have their own Power Levels

The problem we face is that different models of AP, each have their own set of power levels.

Cisco only tells us a number between 1 and X. 1 is full power, every number we add to it is a decrease of 3dB. Some APs go to 5, some go to 8. The same AP on 2.4GHz can have a different range on 5GHz.

This is further complicated by moving an AP from one UNII band in 5GHz to another, still in 5GHz, can completely change its power level range.

What we need is a simple easy way to know exactly what is going on with our power ranges, and what an AP’s power level is set to.

Well, never fear, Cisco has given us tools to help us with this.

The command ” show ap config 802.11a <ap_name> ” will show us lots of information about the power settings, see Table 1 below. We see the number of supported levels, how they map to dBm, the current power level, and whether the power has been set manually or by RRM.

Note: there is a lot of output from this command, the output shown is a snippet from several pages down – you need to press “spacebar” several times to get to this. It usually comes right after the speeds!

 

Table 1: “show ap config 802.11a <ap_name>” output (WLC 5508 8.5 code, 3602 AP)

Tx Power
Num Of Supported Power Levels … 8
Tx Power Level 1 ……………………….. 23 dBm
Tx Power Level 2 ………………………. 20 dBm
Tx Power Level 3 ………………………. 17 dBm
Tx Power Level 4 ………………………. 14 dBm
Tx Power Level 5 ………………………. 11 dBm
Tx Power Level 6 ……………………….. 8 dBm
Tx Power Level 7 ……………………….. 5 dBm
Tx Power Level 8 ………………………. 2 dBm
Tx Power Configuration …………….. CUSTOMIZED
Current Tx Power Level ……………… 3
Tx Power Assigned By ……………….. User

 

In fact, pressing spacebar again gives us more information about the AP channel, we can see this in table 2 below.

Table 2: further output of “show ap config 802.11a <ap_name>” command output (WLC 5508 8.5 code, 3602 AP)

Phy OFDM parameters
Configuration ……………………….. CUSTOMIZED
Current Channel …………………… 149
Channel Assigned By …………….. User
Extension Channel ……………. …. ABOVE
Channel Width………………….. …. 40 MHz
Allowed Channel List……………… 36,40,44,48,52,56,60,64,100,
…………………………………………….. 104,108,112,116,132,136,140,
…………………………………………….. 149,153,157,161,165

 

Here, we can see the current channel set, the channel width, is the extension above or below the current channel (in this case 802.11n +1 channel bonding). We can also see the allowed channels, and whether the channel selection has been set manually or by RRM.

Connecting to the AP (I consoled into the AP CLI, as I did with the WLC), we see it also has some commands we can use.

”show controllers dot11radio 1 freq” will show us the frequency and the channel we are on, as well as other channels supported, see Table 3 below. (In this case “controllers” refers to the hardware controller in the interface, not the WLC – controller).

 

Table 3: “show controllers dot11radio 1 freq” output (WLC 5508 8.5 code, 3602 AP)

Carrier Set: United states (US) (-A)
Uniform Spreading Required: Yes
Configured Frequency: 5745 MHz Channel 149 40MHz, extended above
Serving Frequency: 5745 MHz Channel 149 40MHz, extended above
Allowed Frequencies: * Dynamic Frequency Selection (DFS) only
5180( 36) 5200( 40) 5220( 44) 5240( 48) *5260( 52) *5280( 56) *5300( 60) *5320( 64) *5500(100) *5520(104) *5540(108) *5560(112) *5580(116) *5660(132) *5680(136) *5700(140) 5745(149) 5765(153) 5785(157) 5805(161) 5825(165)

Listen Frequencies:
5180( 36) 5200( 40) 5220( 44) 5240( 48) 5260( 52) 5280( 56) 5300( 60) 5320( 64) 5500(100) 5520(104) 5540(108) 5560(112) 5580(116) 5600(120) 5620(124) 5640(128) 5660(132) 5680(136) 5700(140) 5720(144) 5745(149) 5765(153) 5785(157) 5805(161) 5825(165)
Beacon Flags: 0, Interface Flags 2020105, Interface Events 0, Mode 9; Beacons are enabled; Probes are enabled

 

Note: The text has scrolled over the end-of-line, I left it like this, as this is how it appears on the screen.

Another command typed on the AP “ show controllers dot11radio powercfg ” will show us the number of power levels, the range of power levels allowed, and the current power level setting. (In this case “controllers” again refers to the hardware controller in the interface, not the WLC – controller).

 

Table 4: “show controller dot11radio 1 powercfg” output (WLC 5508 8.5 code, 3602 AP)

Configured TxPower: 17 dBm (Level Index 3)
Allowed Power Levels: 23 20 17 14 11 8 5 2 dBm
Allowed Client Power Levels: 23 20 17 14 11 8 5 2 dBm

So, there we have it. We now have an easy way to determine the power levels in use from the WLC’s and the AP’s perspectives.

See you next time!

 

If you are looking to make your mark in the IT Industry, then NC-Expert offers excellent training courses aimed at relevant IT industry certifications – contact us today to get started.

NC-Expert Blog

Wi-Fi Myth Series - Myth #16: The Controller Knows Best

By Rie Morgan • October 7, 2026
A beautiful dashboard doesn't necessarily mean a beautiful network. There is something wonderfully reassuring about a wireless LAN controller dashboard: everything is neatly organized; access points are green; clients are connected; channel assignments look sensible; the controller reports that Radio Resource Management (RRM) is optimizing the environment; and the health score is sitting comfortably in the high nineties.... life is good. Uhmm... except that users are complaining about dropped calls, sluggish applications, and mysterious connectivity problems. But the dashboard says everything is fine! Welcome to Wi-Fi Myth #16: The Controller Knows Best. Modern wireless controllers are remarkably sophisticated. They collect enormous amounts of information, automate complex decisions, and provide visibility that engineers could only dream of a couple of decades ago. But there's an important distinction between collecting information and understanding what's actually happening in the RF environment... and that's where things get interesting.

Wi-Fi Myth Series - Myth #15: You Can Always Troubleshoot Wi-Fi Without a Packet Capture

By Rie Morgan • September 30, 2026
Modern Wi-Fi systems give us an impressive amount of information. Dashboards show signal strength, channel utilization, retry rates, client health scores, roaming events, application performance, access point statistics, and enough colorful graphs to make almost any troubleshooting session feel reassuringly scientific. And all of that information is useful. I’ll freely admit that most Wi-Fi problems can be investigated without immediately reaching for a packet analyzer. But “most” and “always” are very different words. There comes a point when a Wi-Fi engineer has to stop asking what the dashboard thinks happened, and start looking at what actually happened over the air. This is where packet captures enter the discussion. A packet capture is not required for every Wi-Fi problem. If an AP has lost power, you probably don’t need Wireshark to confirm your suspicions, but when the problem involves association, authentication, roaming, retries, retransmissions, connectivity, intermittent performance, or strange client behavior, packet analysis can turn speculation into evidence . Sometimes, you simply need to see the conversation, and what really happened, to resolve the issue.

Wi-Fi Myth Series - Myth #14: One Speed Test Tells You Everything

By Rie Morgan • September 16, 2026
We’ve all seen it happen: someone reports that the Wi-Fi is slow. A speed test is launched. The little needle races across the screen and, a few seconds later, an impressive number appears. “See? 600 Mbps. The Wi-Fi is fine.” Case closed. Except, of course, it isn’t. A speed test can be useful. It can tell you something about the performance experienced by a device at a particular location, at a particular moment, using a particular test server and network path. What it cannot do is provide a complete diagnosis of Wi-Fi health. That distinction matters because throughput is only one part of the user experience.