you know everytime i bust out cnut, maybe twice a year, i avoid autoupdate, probably because of a problem with it back in the beginning, like every bit of moto software. i dont see any great advantage to autoupdate, granted i deal with less than 500 devices. I once went through all thr trouble of getting powercode to load the versions but it required back end cnut installs and for a while it seemed like every version of software required some new version of cnut. too much PITA for as little cnut upgradeable hardware as we have to do anything auto with them, i think we had done 10 something, 12 something, whatever the last 13 flavor that worked was, and maybe whatever the current is on a couple... but hey, at least its not ubnt
On Wed, Aug 3, 2016 at 11:03 PM, Ken Hohhof <[email protected]> wrote: > My main problem is coming from updating 430 SMs (200+ of them at one > tower) from 11.2 to 13.4.1 so I can replace the APs with 450i. But 430 > needs to go through 12.1.x first. To complicate things, the over-the-air > upgrades to 12.1.x have been failing, so I have a mix on 11.2, 12.1.2, and > 13.x. It just seems a shame to take the 13.x SMs back to 12.1.2. But > using SM Autoupdate doesn’t seem to leave SMs unable to register and > needing a reboot like a direct upgrade. > > With 450 I have no problem with go directly to 14.1.2, do not pass Go, do > not collect $200. 14.1.2 is wonderful. > > > *From:* George Skorup <[email protected]> > *Sent:* Wednesday, August 03, 2016 10:42 PM > *To:* [email protected] > *Subject:* Re: [AFMUG] CNUT question how to autoupdate without > downgrading anySMs? > > I've always used the 'use access point as file server' option. I assume > yours is set the same. What that does is upload the boot image for the > configured SM platform revision (P9, 10, etc) to the AP. The *AP* then > sends the image down to the SMs (via RF private IP) and reports progress > back to CNUT (which is what the "update application address" is for on the > AP's general config page). If you have multiple platform versions selected, > it will start at the top of the list, and cycle through them every 20 > minutes. 'Order by SM number' is helpful, but I usually just do things half > manually. Like I know x AP has only P10 SMs registered, so I turn off > everything except P10. Or I'll go tower by tower and enable auto-update on > a 4 sector cluster and wait for all SMs to finish, then update the APs and > move on to the next. > > The last time I tried 'Update Entire Network' ungood things happened. > > So anyway the problem there is that the AP doesn't care what version the > SMs are running, it just pushes the image to them. If you need to update > specific SMs to a certain version, then the only way is to manually add > their management IP address to CNUT. > > Checking or unchecking the SMs in the CNUT auto discover list does nothing > more than allow you to select them to remove them from the list. Other than > that, it's purely informational, such as auto-update progress which the AP > reports back with SNMP messages. That list is simply the AP's LUID table. > > It's not necessarily bad the way it works, it's just not good. Your > situation though, I don't know what to tell you other than... don't fall so > far behind on updates? ......... ducking. The main problem I have is the > guys "finding" SMs in the trucks and they end up being really friggin old. > Like a 450 the other day on 12.1.2 or something like that. I said, no, bad > dog, find another SM. Not my problem that you can't keep your truck > organized. > > On 8/3/2016 10:01 PM, Ken Hohhof wrote: > > I’ve been using CNUT for 9 years but am a newbie at SM Autoupdate because > I thought it wouldn’t work if you checked Public for the IP address. > > When I enabled Autoupdate for the AP, CNUT immediately started updating > all the SMs it discovered under that AP, without me checking the boxes or > even telling it to update anything. Which surprised me. > > It sounds like you are saying you can check the boxes for which SMs you > want the AP to autoupdate, but that’s not what I observed. What am I doing > wrong? > > In the past, I have always given CNUT the IP address of each SM, and > checked the boxes for which ones I wanted updated. I’m trying to learn how > to use SM Autoupdate. The manual doesn’t seem to be helping me a lot. > > > *From:* Sean Heskett <[email protected]> > *Sent:* Wednesday, August 03, 2016 7:43 PM > *To:* [email protected] > *Subject:* Re: [AFMUG] CNUT question how to autoupdate without > downgrading anySMs? > > yeah what bill and geroge said > > -sean > > > On Wed, Aug 3, 2016 at 6:07 PM, Bill Prince <[email protected]> wrote: > >> What George said. >> >> However.... You can sort by version number,check all the ones at the top >> of the list (version A), upgrade them to B, then do it again and upgrade >> everything to C. >> >> >> >> bp >> <part15sbs{at}gmail{dot}com> >> >> >> On 8/3/2016 4:51 PM, George Skorup wrote: >> >>> It does not understand upgrade path. It will update every SM on the >>> sector to whatever version is enabled and highest in the list for that >>> platform. For example, if you have 13.2.1 on top, then 14.1.2 below that, >>> both checked, it will enable auto-update with 13.2.1. You need to manually >>> add only the SMs that you want to update. >>> >>> Or somebody tell me I'm wrong, because that's always the way it has >>> worked for me. >>> >>> On 8/3/2016 6:28 PM, Ken Hohhof wrote: >>> >>>> Let's say I have an AP with various SMs that are on FW versions A, B >>>> and C. Perhaps new installs got sent out with C on them, but the upgrade >>>> path requires that you go A -> B -> C, and some older SMs have been taken >>>> to B, while some are still on A. >>>> >>>> Is there a way to upgrade all the SMs on A to B, without downgrading >>>> the SMs on C back to B? >>>> >>>> I could be really brave and enable both B and C in Manage Packages, and >>>> hope that CNUT understands you can't go directly from A to C so those SMs >>>> should be updated to B, but the ones already on C can stay there. But I >>>> don't trust CNUT to be that smart, or I'm not that brave. >>>> >>>> >>> >> > > > -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team.
