06-06-2013 08:03 AM
We have ~70APs, spread over around 5 sites up and down the UK. We've found that reboots of APs don't always go to plan, and after firmware updates in the past, we've had to factory reset some of them (they're generally fine after that). This can be a difficult situation when the sites are spread out so much - we have to make sure someone is at each site, armed with a paperclip and ladder just in-case.
I don't think there is currently a way, but thought I'd ask.. as the subject says: Is there a way to select a group of APs at a time for firmware updates?
Feature request if not!
PS - MSM765 controller, and MSM4XX APs
06-06-2013 10:02 AM
You're running a controlled environment, so the unfortunate answer is no. Or rather "no but yes".
The way MSM works in a controlled environment is that the controller will force whatever FW version it is running to the APs. This is necessary, as the FW versions of the controller and APs must be on the same level. The controller can only run one FW version.
You need to remember that we're basically just talking about small Linux computers... they don't generally run more than one OS at a time, excluding virtualization. Getting a controller to run two FW versions simultaneously would thus amount to developing a completely new device. That doesn't really fall under "enhancement request" :-)
The only feasible way to do a gradual upgrade is using two controllers. For example A has FW 5.5, B has FW 5.7. You want to upgrade a group of APs to 5.7, so you just provision them to search for controller B and reboot them. When all your APs are on controller B, you upgrade controller A.
Because of the way things work in some cases you can indeed find yourself in a situation where all APs do not get back to the controller by themselves. There are too many possible reasons to list here. What you could try is that instead of FD resetting a stubborn AP just reboot it. This you can do remotely by shutting down PoE on the switch port where the AP connects to, and enabling it again. Let one AP come back to the network before powering off a second one. I think in your environment it's at least worth a try.
And of course if you do run into issues, you can call support and we'll help you out.
HP Networking Engineer
06-07-2013 03:34 AM - edited 06-07-2013 03:49 AM
Thanks Arimo - great reply..
We do indeed just power off/on the troublesome APs remotely.. it does fix it in most instances; there's the odd occasion where it doesn't work and a FD reset is needed. Just the risk of an issue over multiple sites means that we have to make sure engineers are ready onsite. I like the two-controller idea - expensive!, but a solution none-the-less..
So the current architecture means that a firmware update, updates 'everything' on the AP, including the underlying Linux OS? I'd have thought that the firmware is independent from that?
06-07-2013 09:00 AM
Well now... that's an eternal discussion... what is Linux :-D
Strictly speaking "Linux" refers to the OS kernel, nothing more. Even though "Linux" is generally used to describe them (Ubuntu Linux, Slackware Linux...) following the orthodox way you should talk about "Linux-based operating system". Anything beyond the kernel falls under "distribution".
That's essentially what we're talking about. What we call "Firmware" is actually just another Linux-based OS containing both OS and proprietary and is engineered to perform a very spesific set of tasks :-)
So when you upgrade the "Firmware" what you usually do is you upgrade (i.e. replace) some of the modules. When developers determine that a kernel update is appropriate, that gets done on the same go.
HP Networking Engineer