Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2

Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2

Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-25 08:50:21 - last edited 2025-11-27 01:46:02
Model: EAP772  
Hardware Version: V2
Firmware Version: v1.2.3

I've placed four EAP772 (V2) access points at a client of ours. Their initial firmware was/is v1.2.3, and I'm trying to upgrade them to the current v1.3.4. As a direct update isn't possible according to the firmware release notes, I'm trying to upgrade through v1.3.2. This always fails: the upgrade simply times out after a while of the frontend saying that the upgrade is in progress. The same happens when trying to upgrade to v1.3.4 directly.

 

I don't seem to find v1.2.3 (which the APs came with) on the official firmware list: is this possibly the reason why the upgrade doesn't work? Thanks for pointing me in any direction!

  0      
  0      
#1
Options
1 Accepted Solution
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2-Solution
2025-11-26 09:59:33 - last edited 2025-11-27 01:46:02

Yes, this seems to have done the trick, the updates ran through after fixing the Java heap size of the controller. It's rather unfortunate that the controller does not show any information except in server.log that the heap is full, and that the default heap size isn't automatically set to a larger value than the OS default (Debian presumably sets this to 256M I guess). Okay, so that should resolve this issue!

Recommended Solution
  0  
  0  
#8
Options
9 Reply
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-26 07:28:33

Hi  @modelnine 

 

Thanks for posting here.

Please share a screenshot of the current firmware 1.2.3.

Is there any error message when failing to update to 1.3.2? Please share a screenshot.

 

Did you try updating to 1.3.3? Will it succeed?

 

  0  
  0  
#2
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-26 08:09:42

  @Vincent-TP concerning the current firmware:

I've not tried updating to 1.3.3, as that specifically states that it's only updatable from 1.3.2 according to the firmware page:

The error message is unspecific:

I can access the corresponding AP, and the controller can, too:

I'm rather stumped what to do here. Thanks for getting back to me!

  0  
  0  
#3
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-26 08:33:49

Hi  @modelnine 

 

Thanks for the info.

 

Did you update the firmware via the update button beside the firmware version?

 

Please try manually uploading the firmware versions:

 

Please try both 1.3.2 and 1.3.3.

  0  
  0  
#4
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-26 08:53:46

  @Vincent-TP this (i.e., custom upload) is how I convinced the system to upgrade to 1.3.2 (it offered me 1.3.4 out of the box). I'll try 1.3.3 now.

  0  
  0  
#5
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-26 09:07:18

Hi  @modelnine 

 

I just checked the error message. It says 

Failed to upgrade online. Please check your network config, and make sure the devices can access the controller's HTTPs management port.

 

Did you update it via remote management? If yes, we need to open the TCP port 8043.  Or please update it via local access.

 

 

Which ports do Omada SDN Controller and Omada Discovery Utility use? (above Controller 5.0.15)

  0  
  0  
#6
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-26 09:45:11

  @Vincent-TP yes, port 8043 is open for myself (that's how I made the screenshots of the Omada controller) and also open for the devices to connect to the controller. The controller can also connect to the APs, and vice versa, even though that has to happen through a firewall. Possibly, I've found the culprit: it seems that the Omada Controller does not have enough stack space and fails to serve the file. I've restarted the controller with -Xmx2048m, and now it seems that it upgrades fine to 1.3.2 for one device. I'll try the others.

  0  
  0  
#7
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2-Solution
2025-11-26 09:59:33 - last edited 2025-11-27 01:46:02

Yes, this seems to have done the trick, the updates ran through after fixing the Java heap size of the controller. It's rather unfortunate that the controller does not show any information except in server.log that the heap is full, and that the default heap size isn't automatically set to a larger value than the OS default (Debian presumably sets this to 256M I guess). Okay, so that should resolve this issue!

Recommended Solution
  0  
  0  
#8
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-27 01:45:57

 

Hi  @modelnine 

Great to hear that the issue has been resolved! 

I’d like to confirm whether the error messages are the same for each failed upgrade attempt. If they are, perhaps I should provide feedback to the relevant team for optimization.

Failed to upgrade online. Please check your network config, and make sure the devices can access the controller's HTTPs management port.

  1  
  1  
#9
Options
Re:Failure to update EAP772(EU) v2.0 from v1.2.3 to v1.3.2
2025-11-27 08:13:51

  @Vincent-TP yes, the error message was equal for all tries. Generally, I don't think that this error message itself can be made clearer, as it is by principle correct (the APs WERE trying to access the controller to download the firmware, but/and the controller did NOT respond to the access in a way that served the firmware), and as this is a network access I of course thought that it was due to firewalling between controllers and APs (which the error message insinuates of course), which I could exclude and that's what made the error message so strange. ;-)

 

Generally, what would be really great is if the controller or a thread of the controller fails with a Java exception due to insufficient heap space, that the controller also posts this as a separate error message in the GUI, so that you can see it from the controller itself: increasing the heap space through control.sh is no problem (just adapt JAVA_ARGS), but if you don't know that you need to look in server.log for that message in this specific case (the controller worked for all the rest of its functionality), you'll not think about this as a possible error.

 

Thanks for pushing this to development, and if they need logs to see the Java exception, just get back to me!

  2  
  2  
#10
Options