cnMaestro 1.6.0-r18 Release


Cambium strongly encourages cnMaestro On-Premises customers to apply the package to their existing 1.6.0 OVA.  cnMaestro Cloud accounts have already been upgraded.  Key benefits improvements are

checkmark.jpg    Significantly faster execution of software upgrades for PMP/ePMP sectors

checkmark.jpg    Simplification of cnPilot device “sync” configuration status

checkmark.jpg   Numerous NBI API corrections (On-Premises version)

checkmark.jpg    GUI enhancements

cnMaestro On-Premises is a standalone version of the cnMaestro Cloud application that can be installed in a customer's data center. This document highlights new features and significant fixes in the 1.6.0-r18 patch release.

 Important.jpg   Important

cnMaestro 1.6.0-r18 is a Package release rather than a full OVA Image. It must be applied on top of an existing 1.6.0 On-Premises installation. Please follow the steps detailed on page 129 in the cnMaestro On-Premises 1.6.0 Quick Start Guide (“Updating cnMaestro Software”) to perform a package update on an existing OVA.

Significant Fixed Issues

The following issues have been fixed in cnMaestro 1.6.0:




UI: Tree does behaves incorrectly when expanded and an offline device selected


UI: Multiple GUI Improvements from recommendations in Community post, including pages in Connection Health widget, Devices by Type widget, and Map widget.


Change Mongoose connection to MongoDb native connection in express session


NBI API: Restrict querying Mesh Peers under Tower.


NBI API: Sort functionality is not working.


NBI API: Add "severity=notify" filter support for Events


NBI API: Restrict "state" based filter for alarms APIs.


Configuration: Sync Configuration page doesn't show "Sync Status" properly.


NBI API: api/v1/networks/NID/sites/SID/devices/MAC/mesh/peers/PEERMAC API results in 404 error even though MAC information is available.


NBI API: Incorrect error message when accessing an invalid API.


NBI API: Add radio.color_code to /api/v1/devices/statistics API.


NBI API: The Fields parameter is not working as expected.


NBI APIs: Add AP_MAC for SMs and PARENT_MAC for Wi-Fi in /api/v1/statistics response.


UI: Fixed SNR Bar Graph colors to better differentiate health.


NBI API: Add "id" to the /api/v1/events/ response in order to differentiate individual Events.


NBI API: Round off "radio.24Ghz.clients" and "radio.5Ghz.clients" to an integer in /api/v1/devices/performace api (previously they were floats).


Jobs: Only SMs or Only APs in a Job should run in parallel across sectors


Certificate: Country is missing in the Exported CSR file

Known Issues

The following issues exist in the cnMaestro On-Premises 1.6.0-r18 release:





cnPilot E400 PoE Configuration Error

Configuring PoE Output options for cnPilot E400 devices generate the error” “PoE-Out to an auxiliary device not supported on this platform”.

Workaround: Do not enable PoE option if the configuration is pushed to multiple mixed types of devices like E500 and E400.


WiFi Guest Access Does Not Work with Microsoft Edge Browser

Guest Access on cnMaestro does not work with Edge browser on cnPilot 1.4.0-r12 with 3.2.1-6 and 1.5.0-r4 with 3.3 beta builds.

Workaround: Users need to use supported browsers like Chrome, Firefox, or Internet Explorer (IE) 11.


DHCP Errors after cnMaestro Reboot

When cnMaestro On-Premises is rebooted, after Data Import, sometimes DHCP and Disk Errors are encountered.

Workaround: Explicitly run the dhclient command from the Command Line (accessed through the CLI) after reboot to assign the IP address.


DHCP Option 15 Not Working for cnPilot R

DHCP Option 15 onboarding is not working for cnPilot R devices. These devices cannot use this onboarding mechanism.


Captive Portal Auto Login Fails with Latest Android Devices

Workaround: Whitelist the URL for Google (*


RADIUS Proxy Drops Packets after Retry Exhausted

After RADIUS Proxy Retries are exhausted in cnMaestro On-Premises, all subsequent RADIUS packets are dropped.

Workaround: Reboot cnMaestro.


AP Group Alarm Counts are Incorrect(1.6.0)

Workaround: Alternatively use Network/Site level aggregated alarms.


Device details are not coming in configuration jobs for old jobs in 1.4.0 after migrating to 1.6.0


Not able to Reboot Virtual Machine

Workaround: Login as local user with super administrator or administrator and perform the reboot.

Where to Get Help

There are a number of places to get help with cnMaestro.

  1. Cambium Community: The cnMaestro Forum provides the best place to ask questions and get up-to-date information.
  1. On-Premises Quick Start Guide: This guide walks you through the initial management process and allows you to get onboarded quickly. It is embedded into the cnMaestro image and can be accessed on the Home Page of the UI. It can also be downloaded in PDF format from the Cambium Support website.
  1. Cambium Support: The Cambium Support team is available 24x7 to answer questions and resolve issues.

Thanks for the update.

At a glance:

1) The Dasboard/System/Report/Performance PMP Last Day/5 and 60 Minutes, Last Week/60 Minutes and the 24 Hours reports do not display any Uplink RSSI (dBm) nor Uplink RSSIImbalance data at all.

2) The same reports fail to display the Downlink Modulation data for the last installed SM.  Regardless of which AP it was brought up on.  Last installed SM A on AP X - report fails to display Downlink Modulation data.  Install SM B on AP Y - all data displays for SM A and now Downlink Modulation data is missing for SM B.

3) The Dasboard/System/Report/Performance PMP Last Day 5 Minutes report shows sporadic Uplink Modulation and Downlink RSSIImbalance data across all SMs.  Downlink Modulation data is solid, not one missed block across all SMs, except as noted in item 2. 

4) All 5 minutes data is displying for SM X for a particular hour, but the 60 minute Downlink Modulation data is missing for the same hour.  Is this another case where the timestamps don't line up?  is one local one UTC?

Is all the data transmitted from the SM at the same time or across two or more transmissions?  

How is the 60 minute and 24 Hour data derrived?  An average of 5 minute data or single snapshot at those particular times?

All SMs and APs, 450 vanilla, on 15.1.2 firmware.

Hi Luis,

Issue 1 we already have a JIRA for this. We just need to show RSSI and RSSI imbalance in SM report , no need to have UL/DL for this.

2) Issue 2 we are unable to reproduce and we are getting both Modulations. The downlink modulation value is read from the AP and will only be shown in SM reports and graphs after 5 minutes.of device onboarding.

3) Issue 3 For the SM sporadic issue it can so happen that AP might be sending data at particular intervals and SM might be sending the data at other intervals . The statistics are collected from the AP or SM after 5 minutes from the onboarding time. It can so happen sometimes after AP or SM reboot both may not come and talk to cnMAestro at exactly the same time and this can happen. But if you see the timestamps for AP since all the parameters are queried from AP only you will have solid data in this case and for SMs as some of the parameters are read from AP and AP onboarded or reconnected to cnMaestro before the SM all the values read from SM will shown with particular timestamp and the values read from AP will be shown in different row at other time interval. This seems to the user as if data is missing for the SMs in those rows at that timestamps but this is not correct.  

4) Issue 4 the values shown in 5 minutes interval in one report missing in 60 minutes interval report. Minutes report shows the data collected at each 5 minute snapshot from SM and it is written in database and shown in reports. Same is the case 60 minutes report where the snapshot value of that paramater at the hour end is taken and written to database and shown in reports. Downlink Modulation is read from AP and if AP has not reported the data at that particular time there is a chance that SM might show it as blank in the 60 minutes report. 

5) The 5 minute interval data for SM which are related to SM are sent at the same time. Whereas the SM report also contains downlink data like downlink modulation or downlink throughput which is read from AP which can be sent at the same time or different time based on the onboarding timings as said in point 3 above.

The 60 minutes and 24 hour data is an average of 5 minutes interval data for 60 minutes and an average of 60 minutes interval data for 24 hours data. The average values are true in case of Throughput whether UL/DL.

Where as in the case of other parameters of AP or SM like modulation and RSSI and SM count the values are snapshots at that particular interval of time but not an average.

All the reports and dashboard and performance graphs are calculated in UTC timezone for both AP and SM and no different timezone calucaltions are used.

Hope this clarifies your queries. Please let me know if you need any other details.

We checked our devices and we did not find any issues with the data values reported or the intervals.


1) Not sure I understand - Isn't the data an indication of receive power, on both polarities and the differences thereof?  If so, you would have power received at the SM (Download), on both polarities, and the difference thereof.  Likewise, you would have power received at the AP (Upload), on both polarities, and the difference thereof.  Hence, download and upload power and imbalance.  You guys labeled the data.

2) I'm not saying you aren't getting the data.  I'm saying you aren't displaying it.  I'm not speaking of data missing five minutes after onboarding, I'm talking about days and weeks later.  The missing download modulation data will remain missing for the last installed SM until another SM is brought online, regardless of AP it's connected to.  I can forward you the reports, a picture painting a thousand words and so on.

3) My apologies, but I don't fully understand.  Again i'm not talking about some data missing 5 minutes after onboarding.  I'm talking about data gathered weeks after onboarding and no reboots or offline conditions, at least none reported by cnMaestro and verified by session time of the SMs on the APs.

4) Barring a AP or SM reboot or session drop, why wouldn't the AP report the data? 

5) If I understand correctly, the 5 Minutes data is a snapshot every five minutes starting at time x, for some data.  The 60 minute data can be a snapshot taken once every 1 hour starting at time y for some data, and an average of the 12 5 minute snapshots for other data.  The 24 Hours data can be a snapshot taken once every 24 hours starting at time z for some data, and an average of the 24 1 hour snapshots for other data.

When I look at the tables, I see data missing at some timestamp, so yes I have to believe data is missing.

As for timestamps, are you saying that regardless my time zone, all data is collected and displayed on the dashboard and in reports as UTC and it's up to me to figure out the offset?  So my day runs from 6 am to 6 am CST and all data is thus displayed.  So, if an event displays as having occurred at midnight, it really occurred at 6 pm, my time?

I don't know much, but, I know, if you onboard an SM at some time x local, The Throughput (Last Week) linegraph will start to display data pretty close to that local time.  However, the Current Weekly Usage bar graph will populate at midnight + or - the offset.  In my case, the Usage bar graph populates daily at 6 pm.  Try it in your lab using + or - a one hour offset from UTC and see what happens at 0000 UTC.

I guess what I'm saying is, I don't care what time or offset you use, but let me know what it is and please make all the data correlate.


Not a fan of the unmodifiable, position nor size, software upgrade details pop-up screen.

Is there a way to find out what the differences between the Cloud and On-Prem versions are?

Cloud is at r23 and OP is at r18 - What's the difference?  I'm not saying that you need to put out a new OP version, just want to know what the differences are when they occur.  It saves me from reporting something on the OP that may have already been changed/resolved on the Cloud version.  

The reason I changed from Cloud to OP is that I was having and inordinate number of "Offline" events without any "STA_DROP" or other corresponding event.  I could tell, and reported, that there was a DNS related, but not a DNS access problem, occurring on the APs and SMs.  The units simply were not performing the DNS request.  I was able to minimize the "Offline" events by changing from the cambium URL to the actual IP address on the devices.  Ergo, cnMaestro On-Premises.

With the release of 15.1.3 Beta 5, I haven't had one single "Offline" event without a corresponding/correllating event.  I'm thinking of going back to the Cloud version simply to operate on the latest release and eliminating the maintenance, but I must say I'm one of those guys that likes to keep things locked down and off the Internet as much as possible.  Hmm.


We just updated our cnMaestro on-premises a few days ago to 1.6.0-r18 and it's great, awsome work guys.

I have one proposal for future realeses, when adding new SM to a AP and trying to set a location of SM, we always have to type in the map search tool, village or something that is close to SM. I suggest that default view of map when setting a location should be on the AP's location that SM is connected to, as I am sure, SM is not on the other end of the world, it's always somewhere close to AP. That would save some time when adding a few devices per day, it's not anything dramatic, just a thought.


1 Like


In CnMaestro 1.6.0r25 no for FLOOR PLAN its important for my clients i report this bug and more than week no repair it, its VERY IMPORTANT give a solution.


Hi ktmw

Thats a good suggestion we will try to bring the improvements.


1 Like

Hi jrosello

We will release the patch soon within 2 weeks and let you know.



Great and please make sure that pin is on the map. Because, it is much easier to drag and drop a pin to a certain location, then searching it with a tool - as now, the pin is not on a map until you search for a location.