Maybe try it on a mixed sector and see what happens? It probably isn't
as bad as you think having the 13.x SMs downgrade to 12.1.2 and then
back up to 13.4.1.
I remember sitting at my desk one day and attempting to load a 14.1.2
beta on a sector that was running a previous beta. I hit enable
auto-update and then read some messages on the list or something. Went
back to it after 20 minutes or so and went... WTF, why are all of the
SMs on 13.2.1!? It's that damn package order list! So like 15 SMs
finished in that 20 minutes. Then I did it all over again and it was
fine. And no customers called, even when I updated the AP. That's the
nice thing with Canopy and ePMP, it loads and flashes the image while
continuing to pass customer traffic. Might slow down a little bit, but
that's about it. Now UBNT, you upload the image, hit upgrade and the
customer thinks their service just went down. So they power-cycle it. Argh!
On 8/3/2016 11:03 PM, Ken Hohhof 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 <mailto:[email protected]>
*Sent:* Wednesday, August 03, 2016 10:42 PM
*To:* [email protected] <mailto:[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 <mailto:[email protected]>
*Sent:* Wednesday, August 03, 2016 7:43 PM
*To:* [email protected] <mailto:[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]
<mailto:[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.
