ePMP Software Release 4.7 is now available

I would appreciate it if you could drop Tech Support File collected from AP when it’s running 4.6.1 or any other firmware you can’t upgrade to 4.7 from.
We didn’t notice the described behavior in the scope of the internal testing cycle.

Thank you.

I’ve 4 ePMP 3000 radios on that state, working (passing traffic), but not responding, thus, I’m not able to download the tech file, ssh, telnet or interact with them using SNMP. I will have to do a power cycle and try again. It has been an inconsistent behavior, both from Web UI or using cnMaestro. Last night I upgrade ~300 F300-13L SMs with cnMaestro, ~90% were success upgrades, the rest either timed out (but upgraded successfuly) or failed downloading and I had to retry.

The first three e3K APs I tried upgrading from 4.6.2 to 4.7 had the same lockup behavior (could only ping, and connected SMs continued to work just fine) The next few APs I power-cycled before upgrading and they upgraded fine. I’ll try to reproduce the issue on the next couple APs I upgrade and will grab support files beforehand.

We have been upgrading our lighter loaded APs to start. We’ve tried about 20 APs and 35-40 SMs. So far, we’ve had 5 APs that did not upgrade from cnMaestro. Error message is: SW update file download failed. If we reboot the AP, then try again from cnMaestro, the upgrade still fails. So far, if we upgrade from the GUI, the upgrade is successful. So far it has been all 2000 APs that fail. Fedor, I will send you a tech support file from one of the APs.

We have also had 2 SMs that upgraded, but did not re-connect to the AP until they were power cycled.

Hi all,

If you are upgrading your devices from older fw version to 4.7 through cnMaestro, please make sure that ePMP devices are getting proper time from NTP server.
Otherwise the incorrect time doesn’t allow to pass the certificate validation and the upgrade fails.

Thank you.

2 Likes

Thanks for the update. :+1: Perhaps that’s an alert that cnMaestro could monitor and report? We all can audit our whole network manually, but it’s there a way for cnM to let us know?

Another 3000AP running 4.7 became unreachable. It appeared to be working and passing customer data and was pingable but CNM showed it offline, it didn’t respond to SNMP , SSH and HTTP appears to load the logon screen but does nothing when you try to log in. Power cycle fixed it.

The 3000AP is brand new ( It had 4.6.1 on it when I took it out of the box, I know this because I intentionally only upgraded the active bank and 4.6.1 is still in the 2nd bank). Upgraded to 4.7, configured it and installed it on the tower about 3 weeks ago where it has been working fine until this morning. It was put up to split customers off one of the AP’s that had done this exact same thing when we first tried to update it to 4.7 (worked but was unreachable other than ping) and I posted here about it.

This 3000AP is also the same one I have posted about in another thread regarding what appears to be some odd MU Grouping.

This 3000AP did not revert the software like the others did (however the others failed during the upgrade process while this one had been running 4.7 for several weeks before just suddenly going dark) and still has the factory 4.6.1 in the 2nd bank and 4.7 in the active bank.

After I power cycled it and got back to the office I pulled the Backup Technical Support File if it’s of any use (you also have a support file off this radio from before that I send regarding the odd MU grouping)

Edit: and it is getting the correct time/date from the NTP server.

Just upgraded a couple of SM running 4.6.4 to 4.7. These devices are in NAT mode running pppoe-auto on the WAN interface.
Lan address is 192.168.1.1
I now get a red error “Wireless (WAN) and Ethernet (LAN) Networks must not overlap”
They don’t!

I have updated a couple 3000 epmp sectors, all ac clients, and the only issue I have seen so far are random Clients dropping off of Maestro. Log into the said client and re-input cloud address and all is right again.

Just finished moving the whole network to 4.7, no operationg issues except it disables my snmp despite the communities not being default!
Why should I have to re-enable something that is already properly setup?
How about implementing web auth lockouts? 99% of any attempts are not snmp based, they are either ssh, ftp, telnet or web login.
Snmp can easily be secured by adding a hosts/subnets list (linux has this already) or using a properly configured router to block outside snmp requests like your supposed to do, so stop turning off my snmp!