Does anyone else have a problem with SMs being offline in Maestro with 4.6.2?
A reboot does not fix it. Upgrading to 4.8.1 seems to fix it. We’re well above the minimum firmware version for the bulletin they released about losing access on older firmware.
Any ideas?
Hello @dcshobby,
Thank you for reporting this!
Please tell me if it happens with cloud or with on-premises Maestro?
Is the time correct on the radio?
Could you PM me a techsupport file from one radio on 4.6.2?
This is with Cloud. We don’t set up NTP or time zone on most radios so the time is not correct. I always thought Maestro would at least get the date right. It shows September 3, 2015 as the date and default GMT time. This has never been a problem before and we’ve made no changes.
Tech file sent via PM.
I checked Maestro more and it seems we have several hundred radios that show offline over the last 30 days that we can login into fine and are moving traffic, but they are offline in Maestro. Other versions too like 4.5.5
Every SM is at least as the minimum version required for the bulletin that was released.
Correct time and date is a security requirement for cnMaestro.
Also discussed in this topic:
Good to know. We’ve been fine for all these years without NTP settings.
Why the change in behavior?
Is there a way to mass update the NTP settings with offline radios in Maestro?
We’re in central time zone but is there a way to set it to observe DST changes? I can set it to UTC-05 or UTC-06 but that changes twice a year so the time will still be incorrect by 1 hour depending on the time of year.
Why does updating to 4.8.1 cause it to start working?
Or it would be great if the SM could pull NTP time from AP’s that are configured. It’s much easier to update every AP versus logging into every offline SM.
How come Andrii doesn’t know this is caused by a certificate issue??? These dudes need to talk amongst themselves more.
Anyway, this is caused by a cert issue and you can fix it by upgrading firmwares. I just went to 4.8.1 myself and it fixed all radios that had dropped from cnMaestro.
It has nothing to do with ntp.
Obviously it is a bit weird as some radios on 4.6.2 are sweet and others drop from cloud, but upgrading fw fixed all of mine immediately and tech support told me it was a certificate issue.
See also the note at the top of the PMP 24.2 announcement:
Hello @riddle,
we are pretty aware of it. This is why it is fixed since 4.8.1.
The issue lies at the intersection of 4 years sold ePMP FW, absence of NTP and cnMaestro security polices upgrade.
Hello Andrii,
This is what your engineer told me “… recently the cnMasetro Cloud certificates have been updated, and if the radios are running on firmware version 4.6.1 or lower then they need to be updated their firmware versions to update their CA certificate for seamless communication with the cloud server.”
There was no mention of NTP. I also have some radios with incorrect time that sync fine with cloud. It doesn’t really matter as the issue was fixed with a simple fw upgrade. I just found it odd that we are getting told different things by Cambium, and is the reason that updating ntp settings was not helping your customers.
The truth is i’m still slightly salty with Cambium, as when i’ve had problems in the past, Andrii has told me to email him directly with support files, then he doesn’t reply. Doing this more than once really bothers me - I took time to compile support files, screen shots and write a comprehensive email as requested, only to be ignored, leads to grumpy forum posts.
I think there are a few separate but related problems. Encryption in general is a constantly-evolving field, and TLS/HTTPS standards are also updated regularly. This doesn’t tend to be a problem for desktop software such as web browsers, since they keep themselves up-to-date and people notice if the date on their computer is wrong by a couple of years. However, it does present a challenge for embedded devices that might be running firmware that is many years old.
Devices use HTTPS to communicate with cnMaestro. To successfully negotiate a secure HTTPS connection, the device and the server first need to agree on a set of cryptographic algorithms. Old firmware can only support the algorithms that existed when the firmware was built. On the server, we have to stop supporting algorithms that are no longer considered secure.
Then the server presents a certificate to the device and the device needs to decide whether to trust it. Part of that is deciding whether the Certificate Authority that issued the certificate is trustworthy. cnMaestro recently switched Certificate Authorities (from Comodo to Amazon). Older firmware that didn’t trust the Amazon CA would not have trusted the certificate.
The server certificate also contains a date range during which it is considered valid:
(It’s possible that the date ranges are going to get narrower in the future.)
The device needs to compare the current time with that date range, which means it needs to know the current time. If it believes the time to be
…it will consider the certificate to be invalid.
Keeping the firmware up-to-date ensures that the cryptographic algorithms and certificate authorities match the server. Setting an accurate time on the device (eg. via NTP) ensures that the the Not Before / Not After checks succeed.
