Failed firmware upgrade (6.5r1b to 10.0r7a)

[childs999]

I have bought a new AP130 unit that is currently running 6.5r1b and I want to update this to 10.0r7a. When I attempt to do this via hiveamanger (Cloud) I get an error "device update failed". I've read some other forum posts indicating I may need to jump to a slightly NEWER firmware before upgrading to 10.0

I've attached a screenshot of the error.

Any help would be greatly appreciated.

Thanks

childs999

[samantha_lynn]

Thank you for enabling those debugs. I'm seeing a large number of echo time outs in the buffered log. If you run the command "show log buff | include ah_capwap_echo_timer" without the quotations you can see what I'm referring to.

The HiveManager and the APs have a call and response check-in system that allows them to confirm that each side of the connection is still responsive; these call and response packets are called echos. There is a specific time window within which an AP would need to respond to an echo to be considered still responsive. If the AP misses a certain number of echos back to back, it is considered disconnected until it responds again.

Given the issue you're having with updates, it's possible that the APs are not maintaining a stable enough connection with the HiveManager to complete an update. It's also possible you need to push a complete configuration and reboot the devices, so we might want to try that when we're able to reboot the devices first.

To help with the echo time outs, we'd want to reduce latency on the backend network. If you can run a packet capture and send that to me, I can let you know if we're seeing too much multicast traffic or if we have any particular client devices flooding the network, both of which could lead to failed echo packets.

[stevee]

I've enabled debugs on the five devices.

[samantha_lynn]

The first time you update an AP that is in a factory default state, you will need to push a complete configuration push and not a delta configuration push. The complete configuration update will require a reboot of the device. When you are able to reboot, you'll likely want to try a complete configuration on all of the APs to see if that goes through.

Enabling the CAPWAP debugs will not cause a reboot, and in fact those commands will be erased if the AP does reboot, just something to keep in mind.

[stevee]

Those ports are open to the Internet.

I can't reboot these devices during the day. Will that be necessary at any time in this process?

[samantha_lynn]

Thank you for the Organization Name. The AP that is using 6.5r7 doesn't have a Network Policy applied to it, which is why the update button is grayed out. You'll want to go to Manage> Click on the hostname of the AP> Configure (left hand side menu)> Device Configuration> Choose the Network Policy from the drop down menu under the Network Details section> Save. Then the update option should be available for you back on the Manage Devices page.

For the other APs, could you please confirm the following ports are allowing outbound traffic on your network firewall:

TCP22

TCP443

UDP12222

HTTP80

If they are, would you be able to enable CAPWAP debugs on the APs CLI, replicate the update failure, and then pull tech data from the AP so I can review the debugs for you?

This guide reviews how to enable CAPWAP debugs: https://thehivecommunity.aerohive.com/s/article/CAPWAP-debugs