Recovering the Aironet 1310

Wow! Hasn’t it been a while?!

Isn’t it always the way? You get a new job, a new wife and family and important things like blogging go out the window.

I have been extremely busy with all the above, but will spare you the boring details and get onto the good stuff.

Recently I have been doing a fairly large scale migration from Autonomous Wireless Access points to Light Weight Access points. This means implementing a Cisco Wireless Lan Controller and installing a “light weight” IOS so the Wireless Access points can be managed by the controller. No more dispersed SSIDs or inconsistent security.

The environment, most interestingly, consists of 1200 series, 1250 series and two 1310 outdoor controllers.

From Cisco;

A Cisco Aironet 1300 Series device operating autonomously is an intelligent access point or bridge, capable of functioning as a standalone device. As an LWAPP access point, the Cisco Aironet 1300 Series works along with the Cisco wireless LAN controller to enable centralized configuration and management, application of security policies, and seamless mobility. When operating with wireless LAN controllers, Cisco Aironet 1300 Series Outdoor Access Points/Bridges function only as access points and are not capable of bridging.

The integrated antenna versions feature a radio and high-gain patch antenna for user installations of either point-to-point links or non-root nodes of point-to-multipoint networks. The connectorized versions provide professional installers with RP-TNC type connectors that allow the deployment of nodes with omnidirectional, sector, or high-gain dish antennas for longer links. In all cases, the mounting kit must be ordered separately.

All parts, along with accessories such as the Roof Mount Kit, Wall Mount Kit, cable, antennas, and power supplies, are available on the Cisco Systems® global and wholesale price lists.

So it’s designed for outdoors, which is great! However, at the remote end, it keeps getting screwed up by the upgrade process and I have to nuke both sides to reconfigure them to be autonomous. I’m serious, delete /force /recursive flash:!

That scares the SHIT out of me and I’ve been forced to do it two or three times! The first time we transferred the IOS back onto both ends via console ie. 9600 bps. This was not any fun at all. Logically, there has to be a better way.

After nuking the device back to the stone age, issue the following commands: set IP_ADDR A.B.C.D set DEFAULT_ROUTER W.X.Y.Z set NETMASK XXX.XXX.XXX.XXX tftp_init tar -xtract tftp://IPADDR_OF_TFTP_SERVER/ios.tar flash: set BOOT flash:/c1310-k9w7-mx.124-21a.JA1/c1310-k9w7-mx.124-21a.JA1

The only thing to look out for is make sure the TFTP server is reachable by the access point. And make sure you set the BOOT option to boot to the correct directory and file in flash. As you can see above, I am booting from the flash directory c1310-k9w7-mx.124-21a.JA1 and a file called c1310-k9w7-mx.124-21a.JA1. A simple dir flash: will start to get you on the right track.

  • Brian Jordan

    Hey, just what I needed. I remember stumbling through this years ago. I knew it could be done. Its just remembering the exact command syntax.