Hi,
I wrote a few scripts this afternoon. I think some here might find them useful. They’re up at http://www.nmedia.net/~chris/cancan/
I tested on OpenBSD, but I suspect any Unix-like system with ksh/bash and expect will work fine. I haven’t written expect scripts before, and I didn’t take a lot of time to make these super nice. That being said, they seem to work well, and I was able to accommodate quirky behavior from various firmware versions without much trouble.
The upgrade script does basic error checking and follows all of the basic recommended upgrade paths from Motorola. You can follow the expect log to see if radios failed to upgrade, if they have a firmware version not understood by the script, or if any other part of the script failed to get expected output from the radio.
cangroup - ksh script to call either other script across a range of IP addresses
canreboot - expect script to reboot an AP or SM
canupgrade - expect script to upgrade an AP or SM
The canupgrade script will bring any P9 or P10 radio from 7.0.7 -> 7.2.9 -> 7.3.6 -> 8.1.5.1 -> 8.2.7 -> 9.0. It only upgrades one step at a time, so you have to keep running it until all radios are at 9.0. It will not do anything to a radio already at 9.0, and it will not to anything if the firmware version is not understood. That’s a lot more than I can say about CNUT 
So it won’t brick beta radios in your network, but it will leave note of them so you can manually deal with them. When called from the cangroup script, canupgrade will upgrade an entire range of IPs at once.
The canreboot script simply reboots a radio. The main point of this script is to be used in conjunction with cangroup to reboot an entire tower site.
We allow our radios to sync to any AP. (This is necessary for us on tower sites where we deal with interference – locking customers to specific APs is a recipe for trouble in our experience.) Thus, when we move antennas or reboot APs, customers often end up on the ‘wrong’ AP. Rebooting customer radios helps to distribute the customer load to the ‘right’ AP.
To use the scripts, you need to edit canupgrade and canreboot. Insert your FTP server name, your radio username and radio password at the top of each script.
The canupgrade script requires am FTP server with directories named 7.0.7, 7.2.9, 7.3.6, 8.1.5.1, 8.2.7 and 9.0. Each directory needs to contain the appropriate SMboot.bin (P9 SM/AP image) or boot.image (P10 SM/AP image) for the radio. (And, naturally, no version 7 image supports P10.)
Also, if you need the firmware images, I might be able to help you. You can extract them yourself using CNUT, some P9 and P10 radios, and some creativity.
Two caveats with the canupgrade script:
* If your radio already has a directory with an image, such as if someone manually downloaded the wrong image to the radio, there may not be enough space to download a second image. So the script will fail in the download or burnflash verification process, and you will have to either reboot the radio or delete the offending file to allow the script to upgrade successfully. This is ONLY an issue if you are manually transferring files to/from the radio, which I’m sure most people don’t do these days.
* If your radio is running a buggy firmware image with a memory leak, the download process may fail. Again, the fix is to reboot the radio and run the script again.
These two caveats are minor and don’t require a truck roll, but you will scratch your head trying to figure out what’s going on until you reboot the SM.
I didn’t try and accommodate for either of these possibilities because they are rare and I didn’t want to clutter/slow down the process checking for rare conditions. The good news is that neither of these conditions will ever brick a radio. The worst case scenario is that the download fails, a partial file is left over, the script does not detect abnormalities, and continues with the flash process. This scenario is not such a bad situation - the flash process will fail to verify the integrity of the image, and nothing will happen.
Another interesting scenario we’ve encountered, that we’ve also seen with CNUT:
* Upgrade from 7.3.6 to 8.1.5.1 will take a customer radio offline. We’ve seen this happen in a few cases where a customer only has specific frequencies selected or is otherwise restricted to specific APs to which they have a marginal connection at.
The problem is that, with 8.1.5.1, some P9 radios just don’t link up to marginal APs. The solution is to finish the upgrade to 8.2.7 or 9.0, by checking all frequencies and then running the script again. Of course, if the radio is offline, you have to go on site to do that. Alternately, if all available APs are marginal, then you have to perform the entire upgrade on site. A laptop with CNUT is necessary here. Like I said, this problem is not unique to this script, it happens with CNUT too. It’s an issue with 8.1.5.1 of some sort. Alas, it’s a very rare condition for us.
And no massive network upgrade script would be complete without a WARNING.
WARNING:
This script will upgrade your radios from v7 to v8 without abandon. Thus, your network must be fully capable of supporting v8.
To put it more plainly, you MUST be using hardware scheduling across your network to even attempt to use these scripts. DO NOT use this on networks without hardware scheduling unless you want to spend all week in the field. FOLLOW THE FULL PROCESS TO GET ALL OF YOUR RADIOS RUNNING HARDWARE SCHEDULING FIRST. USE CNUT AND CANOPY SUPPORT IF YOU NEED IT.
This setup does NOT attempt to upgrade anything earlier than 7.0.7. Also it does NOT turn on hardware scheduling or anything like that. If you don’t have all of your radios running hardware scheduling with CANOPYBOOT 3.0 on P9, or have P10 radios, then this script is NOT for you.
Several people downloaded the script. I made a slight fix to canupgrade this morning so that it will send the password after getting the Password: prompt, instead of before it. This works to login 100% of the time instead of 99% like before.