1142 LAP in Operational Status 'Down'

[Inayat Bunglawala]

Hi everyone,

The last three new APs I have received from our supplier (official Cisco 1142 LAPs) have all successfully connected to our 4400 series WLCs but are all reporting as being in an Operational Status of 'Down' ie their A/B/G/N radios are not broadcasting even though the APs are all in an enabled state. Furthermore, there is no steady green light showing on the APs - there is no light showing whatsoever (although they were displaying the familiar red-orange-green lights while they were pulling down the IOS images from the WLCs).

The only strange thing I have noticed is that in the AP config screen, the ‘Mini IOS version’ is shown as being v7.3.x. The other – working APs – we have of the 1142 series show v3.x. I know that controller code v7.2 and above only work with the newer 5500 and 7500 series WLCs. Could this be the issue and have any of you seen this issue previously? I am running WLC code v7.0.230.0.

Many thanks in advance for your assistance.

rgrds,

inayat

[Scott Fella]

Convert it to autonomous and then back to lightweight.  If that doesn't work, then return it. Nothing mush else you can do.

Thanks,

Scott

Help out other by using the rating system and marking answered questions as "Answered"

[Perdue Farms]

Verify in the controller wireless tab then click on the radio's - 802.11a/n and b/g/n on the left side then click network. Make sure the network staus is enabled in the controller. Because even you unshut the radios from the AP, once the AP reboots it will go back to admin down.

[ieee1284c]

This is definitely an issue with recent 1142 AP's tied to 4400 controllers (which can't go above 7.0 code).  The LED will shut off after the AP fully boots on all my recent shipments.  In my case the AP is working fine, just no LED which is a concern.  If I move the AP to a 5500 with 7.2 code, the LED works fine.  If I then move the AP back to the 4400, the LED continues to work.  So as the original poster mentioned, this seems to have something to do with the code shipping with recent 1142's.

I recently RMA'd 5 AP's that I thought were defective and then dug in further when the replacements had the same issue.

[jlhainy]

I am having the same issue as well.  A new batch of 1142's, they update the code, join a controller, I prime my APs.... one of the settings I change is the AP group.  I reboot the AP and the LED dies.

[Scott Fella]

Is the status up or down? Is the LED off and the ap is functional? These are two different things. Does the switch the ap is connected to have enough power to provide the AP? Disabling the lights is a global change or a change to each AP.

Can you provide more info

Sent from Cisco Technical Support iPhone App

[jlhainy]

Hi Scott,

It's the same as the others who have posted.  This is a brand new 1142 AP.  It updates its code to 7.0.235.3, after the code upgrade the LED still appears to work.  I prime the AP and the only thing that I do is assign an AP group and give it a hostname.  The AP reboots again and then the LED dies.  You don't even know the AP is powered on unless you are consoled in.  It gets its config just fine, it joins the WLC fine, it services clients just fine.  It has plenty of power.  For all intents and purposes, the AP functions.  What is not happening is the fact that the LED is off.

Now, this is only happening with new 1142s.  I have several older 1142s in production and they don't have an issue at all.  I just got a shipment of 16 new APs and I updated the first 4 and they all have the same issue, but the other 400 I have in production have no issue at all.  There is something up with these new APs.  I don't know what code they shipped with, but if it was 7.2 or 7.3, my hunch is they didn't like downgrading to 7.0.235.3. 

[Leo Laohoo]

I am having the same issue as well.  A new batch of 1142's, they update the code, join a controller, I prime my APs.... one of the settings I change is the AP group.  I reboot the AP and the LED dies.

No problem with the LED going off after it joins the controller.  It's a bug.  Just invoke the "config ap led all" and all should be good.

[jlhainy]

yeah.  I just got that.  That appears to have fixed it.  It is kind of interesting though because you have to apply the command while the APs are associated to the controller for it to take affect.  If you apply it, and then join an ap, it doesn't take. 

Interesting yet slightly annoying bug.  I just need to change my priming process a little.

Scott,  sorry bro.  I re-read your comments and saw that you said the same thing as leolaohoo. 

[Scott Fella]

Haha... No problem. Just remember that when the ap is in a downloading state, you can't make any changes to that AP. any changes mad during that time will not be saved. Only when the AP is in the run state will any changes that are made will be saved if applied.

Sent from Cisco Technical Support iPhone App

[Inayat Bunglawala]

>>Just invoke the "config ap led all" and all should be good.

Where do you invoke this command? I consoled into the 1142 LAP (while it is connected to the WLC) and it does not allow that command.

[Scott Fella · Accepted solution]

That command is ran from the WLC CLI.

config ap led-status enable all

Sent from Cisco Technical Support iPhone App

[Inayat Bunglawala]

Ignore my email: I ssh'd into the WLC and invoked that command from there. Many thanks!

[Scott Fella]

Did that fix the issue?

Sent from Cisco Technical Support iPhone App

[Inayat Bunglawala]

Yes, it fixed the issue. The command 'config ap led enable [AP Name]' once run from the WLC fixed the problem. Looks like a bug with the new batch of 1142Ns. Thank you for your help!

[jlhainy]

For those interested in looks like this is Bug ID CSCud76044.  This bug states that the config ap led-state enable command does not solve the issue.  It appears that this issue has manifested only on APs runing bootloader version 12.4(23c)JA5, which explains why it's only happend on newer 1142s.

Unless the boot loader version is specific to hardware model, this could come up on other models of APs.