Wireless Access

This question is more of a curiosity question then anything.  We had a lightening strike hit our campus and even with surge protectors and grounding bars and all that stuff it still managed to fry a good amount of equipment.  Among it was 10 AP105's.  some of them are completely dead.  A few others get power and if i watch the console i see a message about not being able to find the boot image or the OS is corrupt.  So the question is, is it possible to get the OS reloaded onto the AP?  These will never go back into service, i really only want to do this just to see if its possible and because i am a nerd and like the challenge. 

Any thoughts? 

Heres a good post on the image and bootloader files -

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/AP-and-controller-images/td-p/64416

Thanks, thats a good read.  Now the question is where do you get the files? I dont see them in the list of downloads...

mwallen

The first thing you need to ascertain is whether or not the ethernet port is fried, so break into apboot and type:

apboot> dhcp

If the AP cannot get an IP address, and the cable is known to be working (i.e. verify if possible with a known working AP), then the missing OS issues is secondary.

If you get an IP via DHCP, the next step is to make sure the AP sees the controller. It will do this via ADP, DNS, DHCP options etc. If unsure, at a minimum, make sure the AP can ping the controller IP, do this from the apboot prompt.

If you have an IP address and can ping the controller IP, in 99% of the cases it's going to recover itself (my guess, personally, after lightning strike is that you will find the DHCP doesnt work and the data pairs are blown). You can test the discovery from the apboot, assuming there is no serverip and master set, by typing

apboot>  tftpboot

this should trigger the AP to try and discover the controller and boot up off TFTP. After doing so, it would try to download the image, save to flash and reboot.

there are other ways to do this, but the above process should work fine where there is an active controller present.

regards

jeff

in addition to last post and inline with the post by MattF, upgade os <image name> will try to contact the controller, download the image and burn it to flash - which would also solve the issue.

The only difference is that you have to know the name of the image file (which is always on the controller), and that's easily found from "printenv" command output, as param "bootfile"

bootcmd=boot ap
autostart=yes
bootfile=mips32.ari
ethaddr=00:24:6c:c2:eb:e2
stdin=serial
stdout=serial

so you have a choice of the manual method that doesnt actually boot the AP until you're done, or the quick method using tftpboot to quickboot the AP, and then letting the software handle the upgrade for you.

regards

-jeff

For clarification, the files are part of the controller AOS, when the APs join and have a firmware mismatch the file is TFTP'd (or FTP'd) to the AP from the controller. when you use the manual method your acting like an AP and requesting the file from the controller - you initiate a TFTP download from your client asking the controller for the file and the controller supplies it to you.

Thanks for the replies everyone.  I will see if i have time to mess with this a bit today.  Since this is for fun real work comes first unfortunately :)