I convert 1231g to lwapp.
When I console the AP, I get this message "*Mar 1 00:00:23.535: %LWAPP−5−CHANGED: LWAPP changed state to DISCOVERY
*Mar 1 00:00:23.550: LWAPP_CLIENT_ERROR_DEBUG: lwapp_crypto_init_ssc_keys_and_
certs no certs in the SSC Private File
*Mar 1 00:00:23.550: LWAPP_CLIENT_ERROR_DEBUG:
*Mar 1 00:00:23.551: lwapp_crypto_init: PKI_StartSession failed
*Mar 1 00:00:23.720: %SYS−5−RELOAD: Reload requested by LWAPP CLIENT.
Reload Reason: FAILED CRYPTO INIT.
*Mar 1 00:00:23.721: %LWAPP−5−CHANGED: LWAPP changed state to DOWN".
I read from "Cisco-Lwapp Upgrade tool troubleshooting tips".
He told me that "You have an SSC AP. Once you convert to LWAPP AP, add the SSC and its MAC address under the AP
Authentication list in the controller."
I don't know how to get the ssc key from the AP.
Please advise me.
These messages show that the SSC certificate was not generated when the AP was converted to LWAPP. Just convert the AP back to IOS and reconvert it to LWAPP. Make sure when you convert it to LWAPP you use version 2.0x of the Lightweight Upgrade Tool. If you just copy the LWAPP image to the AP using the archive download-sw command the SSC will never be generated.
There are couple of things here.
1) First you need to have a self signed certificate on the AP . See the debug messages your AP didn't have a SSC .
2) Debug pm pki enable on the controller will give you the hash key for certificate. Just take the ouput in a notepad and search for the hash key .
I have exactly the same problem on the same hardware (AIR-AP1231G-E-K9).
However the boot loader won't accept the very same image the AP ran before the upgrade (c1200-k9w7-tar.123-8.JEA1).
The boot loader just says after downloading the IOS image from my tftp server:
Premature end of file
ERROR: Image is not a valid IOS image archive.
Then the AP continues to boot the LWAPP image from the flash memory.
I downloaded a fresh file from Cisco, so I doubt that's the cause of my problems.
What IOS image and of what age is accepted by the boot loader?
The AP can be converted back to Autonomous (IOS) using the following method (then try using the LWAPP Upgrade tool for the conversion to obtain the SSC Key);
Reverting the Access Point Back to Autonomous Mode
Converting a Lightweight Access Point Back to Autonomous Mode
You can convert an access point from lightweight mode back to autonomous mode by loading a Cisco IOS Release that supports autonomous mode (Cisco IOS release 12.3(7)JA or earlier). If the access point is associated to a controller, you can use the controller to load the Cisco IOS release. If the access point is not associated to a controller, you can load the Cisco IOS release using TFTP.
Using a TFTP Server to Return to a Previous Release
Follow these steps to revert from LWAPP mode to autonomous mode by loading a Cisco IOS release using a TFTP server:
Step 1 The static IP address of the PC on which your TFTP server software runs should be between 10.0.0.2 and 10.0.0.30.
Step 2 Make sure that the PC contains the access point image file (such as c1200-k9w7-tar.122-15.JA.tar for a 1200 series access point) in the TFTP server folder and that the TFTP server is activated.
Step 3 Rename the access point image file in the TFTP server folder to c1200-k9w7-tar.default for a 1200 series access point, c1130-k9w7-tar.default for an 1130 series access point, and c1240-k9w7-tar.default for a 1240 series access point.
Step 4 Connect the PC to the access point using a Category 5 (CAT5) Ethernet cable.
Step 5 Disconnect power from the access point.
Step 6 Press and hold MODE while you reconnect power to the access point.
Step 7 Hold the MODE button until the status LED turns red (approximately 20 to 30 seconds) and then release.
Step 8 Wait until the access point reboots, as indicated by all LEDs turning green followed by the Status LED blinking green.
Step 9 After the access point reboots, reconfigure it using the GUI or the CLI.
From this doc;
Hope this helps!
This is the exact procedure I carried out the other day.
I did this while my laptop was running HyperTerminal connected to the console port of the 1231 in question.
That's why I know the boot loader won't accept the most recent IOS images.
I've tried both c1200-k9w7-tar.123-8.JEA and c1200-k9w7-tar.123-8.JEA1.
I have yet to try c1200-k9w7-tar.123-4.JA, but I'd rather have someone's opinion on the matter before I go ahead with another unsuccessful attempt to gain control over this 1231.
It might be that this particular 1231 was shipped with an early pre-release boot loader.
If that's the case, then I see no alternative other than asking my reseller for a replacement flash card, if such is available or even possible.
Anything is possible :). Just curious did you rename the access point image file in the TFTP server folder to c1200-k9w7-tar.default for a 1200 series access point?
Yes Rob, tftpd running on FreeBSD 6.1 said:
10.0.0.1: read request for //c1200-k9w7-tar.default: success
I've noticed the AP uses tftp://255.255.255.255/c1200-k9w7-tar.default as the path, but given the above message from tftpd, this should indicate that the request was understood and carried out to the letter.
Or should I use the Upgrade Tool instead of my tftpd?
(And yes, we did use the Upgrade Tool in the first place; three of our other 1231 were successfully upgraded and runs happily lobotomized.)
I guess the netmask should be 255.0.0.0 since we're using class A addresses.
I like your sense of humour here (Lightweight=Lobotomized very good :)
You kind of lost me though on this line;
Or should I use the Upgrade Tool instead of my tftpd?
We are still trying to downgrade to IOS?
Rob, since we are both into the IT business, there's no way to get things done without some crazy humour every now and then.
Yes, I'm still trying to get a normal IOS image into this little baby.
I just tried c1200-k9w7-tar.123-4.JA.tar and got the same result as before.
This makes me wonder if the tftp service gets the job done at all.
We see the initial success message from tftpd, but a packet trace using tcpdump revealed next to nothing.
The boot loader's use of the broadcast address might be the reason why nothing's happening.
I admit this is the first time I have ever used the boot loader to inject an image into an AP.
Upgrading the APs using IOS and tftp has always worked flawlessly.
The same goes for upgrading the switches as well.
Maybe there's something wrong with my inetd/tftpd setup on my FreeBSD 6.1 box.
I run inetd the standard way using inetd_enable="YES" in /etc/rc.conf.
Next tftpd is run on demand by inetd as tftpd -l -s /tftpboot -u tftp -w.
And /tftpboot/c1200-k9w7-tar.default is a hardlink to /tftpboot/c1200-k9w7-tar.123-8.JEA1/c1200-k9w7-tar.123-8.JEA1.tar or whatever the image I'm trying to upload.
The permissions on these image files are 644(-rw-r--r--), and the files are owned by root:tftpd.
The IP address is set to 10.0.0.3/8 by using ifconfig xl0 inet 10.0.0.3 netmask 255.0.0.0.
The default gateway is then set to 10.0.0.3 using route add default 10.0.0.3.
Do you know of anything that is special with FreeBSD/inetd/tftpd/my setup and thus preventing this combination from uploading IOS images to the boot loader?
It's way past bedtime in Norway as I write these words, and you might not get a reply until eight hours have passed.
Yes,crazy humour does help! It sounds like you know more about TFTP than I ever will :) I would suggest trying a different TFTP Server setup;
Maybe try this (highly recommended version)
Solar Winds tftp
Worth a try?
The TFTP server you suggested did the trick!
I try to use Unix as much as possible at my shop, but this time Windows XP and SolarWinds' TFTP server came to the rescue.
It's seems SolarWinds are more forgiving when it comes to using the (limited) broadcast address than stock FreeBSD tftpd is.
There might be something wrong or missing with my usual tftpd config.
Anyway, thank you for suggesting SolarWinds' TFTP Server, it did the job quite nicely, and you've earned five more points today.
Great stuff! Thanks for posting back with your solution (and the 5 points :) Remember, you and I will try not to be LWAPP too often.