Wireless Access

Any possible way to abort the firmware upgrade?

I made the mistake of using TFTP and it is taking over 1 hour to copy the firmware over and I cannot SSH into the controller at this time.

Is there any way to abort this process?

Please contact TAC so you are guided through this properly.  Typically if you disconnect the connection, it will not finish.  If you cannot SSH into it, that is a problem.  Please contact support.

A simple ctrl-C won't work in this case?

The controller is in a remote location unfortunately and no console access.

I guess TAC is the best solution?

I would say you should be able to.  If you cannot get into the CLI again, something must have occurred.  Please contact TAC to get this sorted.

ctrl-c didn't work.

I do have remote PDU access to the controller. I could possibly reboot it.

The firmware hasn't finished copying over therefore I should be able to reboot it safely. I think anyway...

ctrl-c is a last resort.  TAC is the best way.

In my experience you can not ssh into the controller while it is TFTPing.  I think this is normal behavior.  Once it is done you should be able to log back in.  An hour or more is common when TFTPing the images.

---

@Evan W wrote:

In my experience you can not ssh into the controller while it is TFTPing.  I think this is normal behavior.  Once it is done you should be able to log back in.  An hour or more is common when TFTPing the images.

 

---

Probably the biggest issue is that TFTP really should not take that long, and some TFTP servers cannot transfer files over 50meg and hang as a result.  It is much faster to use FTP in any situation that you can.  With that being said, some sites are on slow WAN links and it is much better to copy the file to a local host and then TFTP or FTP it from there.

the beauty of this.

they are on a different subnet but a different subnet.

It is still going, 4 hours and counting

I've seen this once or twice.  My solution was to stop the TFTP service/application on the system hosting the image; it should cause the controller to abort the connection.

I decided to leave it running to see what would happen.

I started yesterday at noon and at 645am this morning it was still going.

I performed a hard reboot via a PDU and it came back online.

This controller since it is a 3200 has been having memory problems (running out of memory) and that could be the cause of this issue as well.

What version of code are you running and upgrading to?  Have you upgraded the 3200 to a 3200XM (extra memory)?  The later versions of code wont work well without additional memory in an original 3200.

I was going from 6.1.3.3 to 6.1.4.0

I do not have the XM memory module unfortunately. I believe upgrading to 6.1.4.0 is the last time we will be upgrading the AOS and in the future replace with a 3600 controller.

Do you recommend against upgrading to 6.1.4.0 on a 3200?

I recommend against the upgrade, but it is probably "officially supported".  I would definitely get the upgrade kit for your 3200 so you can upgrade software beyond what the original 3200 is capable of.  The upgrade is 3200-MEM-UG and runs ~$400 list price (USD).

I use the CLI almost exclusively and have done many TFTP upgrades, but I have not done a 6.1.3.x upgrade on a non-XM 3200.  I dont trust the new features without the additional memory.

As others have said, I have had to kill the session a couple times due to TFTP "hang ups", but it has never been a huge issue for me.

I typically watch the TFTP server and if I see the bytes in/out stalled, I will kill it and try again.

What about a 3400 controller?

3400 controllers are OK with any software and features.  I have stil seen TFTP get hung up, but its rare.  Thats not really a problem with Aruba gear, but a general issue with technology where sometimes things get into a state where they cant recover gracefully.

ok thanks.

I try to use FTP or SCP when I can but in this case the 3200 was at our datacenter and so was the TFTP server but on a different subnet. So I thought it should be fine but I guess not.