Solved: ERROR!!! Command is disabled.

brock0150 · ‎02-12-2008

I have a lwapp 1130 here and it's no longer associated with the controller. I issued the clear lwapp private-config, it went through and cleared the config. Now when I try to issue the lwapp commands to set the ip and such i get ERROR!!! Command is disabled. I read that this means the static configuration is locked, but it did not say how to "unlock" it. Any ideas or suggestions on how to get this re-enabled.

This information has been added in the following Document - https://supportforums.cisco.com/docs/DOC-21897

smgreenshaw · ‎02-15-2008

Hi,

In case anybody else gets stuck like I did, here's the procedure we eventually knocked together for recovering our locked out 1240AG AP's:

Recovery of Cisco 1240AG AP

This procedure tested working 14/02/08 with an AP with the default WLAN controller password left in.

Requirements:

â€¢ Cisco IOS WAP image (c1240-k9-w7-mx.124-10.b.JA)

â€¢ Cisco LWAPP recovery image (c1240-rcvk9w8-tar.123-7JX.tar)

â€¢ Cisco LWAPP upgrade tool

â€¢ TFTP Server

â€¢ Local PSU (not POE)

Local PSU is required - process doesn't appear to work with Ethernet connected as boot doesn't stop.

Power up WAP holding MODE button until LED turns Purple (approx 20 secs)

Console should go through boot banners, notice no Ethernet and dump to ap: prompt.

ap: IP_ADDR=a.a.a.a

ap: NETMASK=m.m.m.m

ap: DEFAULT_GATEWAY=g.g.g.g

ap: tftp_init

(message confirming tftp available should come back)

Plug in Ethernet on correct vlan to see WLAN controller (i.e. a.a.a.x).

ap: ether_init

Via your friendly local tftp server boot off a full IP image, in this case I extracted from the full .tar file and placed it on tftp serverâ€¦

ap: boot tftp://x.x.x.x/c1240-k9-w7-mx.124-10.b.JA

AP should boot to ap> prompt and initialise. It may well generate r0.core and r1.core dump files as radio firmware not available.

Once settled:

ap> en (password in our case was the default) ap# conf t

ap(config)# int bvi1

ap(config-if)# ip address a.a.a.a m.m.m.m

ap(config-if)# line vty 0 4

ap(config-line)# login local

ap(config-line)# exit

ap(config)# username test password aptest

ap(config)# exit

Once this is done the AP should be alive on the network and you should be able to ping and telnet to it and logon. Enable secret will still be the default password.

Now you need to put the logon details in an ip.txt file for the Cisco WLAN recovery tool, we used the recovery tool's own tftp server and didn't enter WLC details.

Click Start and Cisco tool should contact the AP, telnet in, modify the config and download the recovery image and a basic config. Once done it will reboot the AP and it will go into lwapp discovery mode.

Steve.

View solution in original post

mike · ‎02-12-2008

I just ran across a similar situation.

You'll need to hold down the "Mode" button during startup for a few seconds. That'll get you out of the controller mode, and should allow you to set the controller IP and so forth.

That said, if the AP is on the same subnet as the controller, you wouldn't need to set the IP address on the AP. That's supposed to be one of the benefits of using LWAPP APs.

Rob Huffman · ‎02-12-2008

Hi Brock,

Just to add a note to the good info from Mike (5 points for this Mike!)

Here is why the command may be locked;

***The LAP was previously registered to a WLC, but the username/password was not changed from the default

So try this;

Once your LAP successfully registers with the WLC, the static LWAPP configuration commands (discussed in the previous section) are locked out and are no longer accessible. In order to re-enable the commands, you must have set the username and password while the LAP was joined to the previous controller.

When the LAP is registered to a controller, use this controller CLI command to set the AP's username and password:

config ap username password

From this doc;

http://www.cisco.com/en/US/products/hw/wireless/ps430/products_tech_note09186a00808e2d27.shtml

Hope this helps!

Rob

smgreenshaw · ‎02-13-2008

Hi,

I am having exactly the same issue. Is there no way of forcing a LWAP to it's default 'out of the box' state without requiring the WLC, do you know?

Regards,

Steve.

Rob Huffman · ‎02-13-2008

Hi Steve,

If the LWAPP AP did have the username and password changed while the LAP was joined to the controller then this is available via the AP's console connection.

Here is one method;

Manually Resetting the Access Point to Defaults

You can manually reset your access point to default settings using this EXEC mode CLI command:

--------------------------------------------------------------------------------

Note This command requires the controller configured Enable password to enter the CLI EXEC mode.

--------------------------------------------------------------------------------

clear lwapp private-config

From this Troubleshooting doc;

http://www.cisco.com/en/US/docs/wireless/access_point/1130/installation/guide/113h_c4.html#wp1091061

Hope this helps!

Rob

mike · ‎02-13-2008

Rob's right. That command should clear out the configs.

If that doesn't work for you, hold the "mode" button while the AP is starting up. That'll get the AP out of the controller mode (I forget exactly how many seconds...3 or 4? Until the light turns amber). Once there, you should be able to issue the commands that'll clear the configs.

It's a bit of a pain, so just keep playing around with it.

smgreenshaw · ‎02-14-2008

Hi,

Thanks for your replies, guys.

I've tried resetting the device (1242AG) by holding diown the mode button. It shows:

button pressed for 20 seconds

process_config_recovery: set IP address and config to default 10.0.0.1

process_config_recovery: image recovery

Upon restarting though I still get the ERROR!!! when attepting to set the lwapp private-config. I also note that a 'show lwapp private-config' indicates that there is still a default gateway set. Again, I cannot 'clear' that due to the ERROR!!!

Steve.

mike · ‎02-14-2008

Hey Steve,

Can you put that AP on the same subnet as the controller, and try to join it? You'll be able to reset it to factory configs then.

Also, are you getting any error messages during the operation of the controller when you're not typing in commands? If it doesn't spit errors are you, and doesn't keep restarting itself, it's out of the joined mode. At that point, you may not be able to issue the clear private config command, but you should be able to set the lwapp ap controller ip address command (I think that's what it is).

smgreenshaw · ‎02-14-2008

Hi,

Eventually ended up going the looooong way round. Returned the unit to autonymous mode and then used the upgrade tool etc. to take it back to LAP. Associated with the WLC no problem and is now back under control.

Problem arose due to the WLC and LAP having been setup a while ago in a test lab by external contractors. They did not give it a new username / password. They then re-installed the WLC on the live environment - leaving me with an orphan LAP.

At least I now know that if all else fails it is possible to rescue stubborn LAPs!

Thanks again for your input guys.

Steve.

mike · ‎02-14-2008

Damn contractors.

;)

smgreenshaw · ‎02-15-2008

Hi,

In case anybody else gets stuck like I did, here's the procedure we eventually knocked together for recovering our locked out 1240AG AP's:

Recovery of Cisco 1240AG AP

This procedure tested working 14/02/08 with an AP with the default WLAN controller password left in.

Requirements:

â€¢ Cisco IOS WAP image (c1240-k9-w7-mx.124-10.b.JA)

â€¢ Cisco LWAPP recovery image (c1240-rcvk9w8-tar.123-7JX.tar)

â€¢ Cisco LWAPP upgrade tool

â€¢ TFTP Server

â€¢ Local PSU (not POE)

Local PSU is required - process doesn't appear to work with Ethernet connected as boot doesn't stop.

Power up WAP holding MODE button until LED turns Purple (approx 20 secs)

Console should go through boot banners, notice no Ethernet and dump to ap: prompt.

ap: IP_ADDR=a.a.a.a

ap: NETMASK=m.m.m.m

ap: DEFAULT_GATEWAY=g.g.g.g

ap: tftp_init

(message confirming tftp available should come back)

Plug in Ethernet on correct vlan to see WLAN controller (i.e. a.a.a.x).

ap: ether_init

Via your friendly local tftp server boot off a full IP image, in this case I extracted from the full .tar file and placed it on tftp serverâ€¦

ap: boot tftp://x.x.x.x/c1240-k9-w7-mx.124-10.b.JA

AP should boot to ap> prompt and initialise. It may well generate r0.core and r1.core dump files as radio firmware not available.

Once settled:

ap> en (password in our case was the default) ap# conf t

ap(config)# int bvi1

ap(config-if)# ip address a.a.a.a m.m.m.m

ap(config-if)# line vty 0 4

ap(config-line)# login local

ap(config-line)# exit

ap(config)# username test password aptest

ap(config)# exit

Once this is done the AP should be alive on the network and you should be able to ping and telnet to it and logon. Enable secret will still be the default password.

Now you need to put the logon details in an ip.txt file for the Cisco WLAN recovery tool, we used the recovery tool's own tftp server and didn't enter WLC details.

Click Start and Cisco tool should contact the AP, telnet in, modify the config and download the recovery image and a basic config. Once done it will reboot the AP and it will go into lwapp discovery mode.

Steve.

mike · ‎02-15-2008

Right on.

Thanks for the info.

brock0150 · ‎02-15-2008

Thanks this worked fine converting it back to autonomous mode. although it somehow lost it's radio's and can't be converted back to lwapp. i believe this wap had issues anyways. So it would of worked fine if it wasn't for that.

smgreenshaw · ‎02-15-2008

Hi,

To get the radio up you'll actually have to untar the full package (c1240-k9w7-tar.124-10b.JA.tar) as this has the firmware for the wireless:

AP: tar -xtract tftp://x.x.x.x/c1240-k9w7-tar.124-10b.JA.tar flash:/

The workaround we had was specifically to get it back to a 'configurable' state so that we could use the upgrade tool to convert it to a clean LAP. There is no need or capacity to use wireless for this process - it's all done over ethernet - so we did not load the radio firmware (hence the r0.core and r1.core dumps).

Hope that helps ...

Steve.

Rob Huffman · ‎02-15-2008

Hey Steve,

Thanks for posting up this very good resolution! 5 points from this end for this great info.

Thanks again,

Rob