Having a real problem getting off the ground with my first 4 Cambium Products ... need to connect a e500 to a gateway router as an AP plus use 2 ePMPs to backhaul a second e500 as an AP to the same Router ... I have been able to connect to the local user interface on one e500 and one ePMP however when I onboard the S/N's and Approve them, cnMaestro just spins its wheels saying it is waiting for the devices ... I can manually login to the cambium website on the lan side of the gateway router so really not following what is going wrong ... the documentation suggests the ID needs to be set in the UI but I don't see anywhere for that to occur ... most of the online support appears to be for an older verion of cmMaestro. Went looking for a youtube video on how to onboard a device but the only one appears to be in Spanish. The cmMaestro feature videos all start after the devices have been onboarded.
OK so a couple of issues that tripped up here ... One is that the Local UI for the e500 "CHANGES" and no longer offers the cnMaestro configuration ... I had noted that to myself earlier but didn't expect that was the issue ... Once the e500 was FACTORY RESET and the cnMaestro details were entered the device AUTOMATICALLY boarded ... the second thing that tripped up here was an expectation that these devices should KNOW where HOME was ... WHY are we needing to enter in the Cloud address? I expect the reason these devices would board was because they didn't have the Cloud url by default.
Perhaps some changes should be made in the next release of firmware to identify in the Documentation that the Local URL must be used to enter in the Cloud address AND/OR the cloud address be entered in by default ... assuming there is a reason for the ability to change this address. (perhaps the local server app) regardless, in my case it would have save me countless hours if this url had been preprogrammed.
Hi
Which firmware was the device running?
By default all cnPilot out of box talks to cloud.cambiumnetworks.com and user doesn’t need to configure them.
The device needs to be claimed via serial no on your cloud account.
For On-Premises server the URL has to be entered on the device.
Please send me version details and the exact steps followed via private message.
Regards
Rupam
Hi,
Recreated same setup in our lab with 3.4.2-r36 loaded. End to end devices gets ip from backend DHCP and devices gets onboarded to cloud by Serial number onboarding, no need to give cloud URL in the DUT UI, it will automatically try to onboard to cloud. Only thing you need to claim the serial numbers in the cloud cnMaestro(mandatory).
Router+DHCP ---- e500 poe adaptor1 ---- eth1 e500-1 - eth2 e500-1 ---- ePMP AP~~~~ ePMP SM---- eth2 E500-2 - eth1 e500-2 ---- e500-poe-adaptor2
Please make sure below things are correct in your setup,
- My understanding is that your first E500 itself is not getting IP from DHCP, so you configured static ip in E500, there could be problem in the DHCP server. We need a capture of the Meraki router port where E500 is connected or try connecting a laptop to the Meraki router and check whether it is getting ip.
2. “eth2 e500-1” port need to be connected to the “MAIN” port of ePMP AP not to the “AUX” port.
3. “eth2 E500-2” port need to be connected to the “MAIN” port of ePMP SM not to the “AUX” port
4.“e500 poe adaptor2” should be used only for powering up the e500-2, it shoudn’t be connected to the
network, this will cause a loop.
On the CnMaestro onboarding,
- Hope you are using “cloud” cnMaestro with serial number onboarding and not option 43, for which you need to make sure claiming the Serial numbers of E500's and ePMP's in the CnMaestro. In 3.4.2-r36, checked by default device tries to onboard to cloud as the fourth option (after static,opt 43 and 15).
For further debugging we need techdump of E500's with “logging cnmaestro 7” enabled and also the Meraki router capture to check DHCP is working.
Please correct me if any of my understanding of your setup is wrong.
Thanks,
Divakar
The previous replies weren't relevant to the original issue because the ePMP I'm using is a Force 180 which only has one port. Thankfully I was able to get a solution by calling back my supplier ... after an hour and a half of tweaking, I was up and running. Preliminary test results are promising so it looks like these products will do what I need them to do. As to the DHCP issue, the gateway "CISCO" router is working as designed, the DHCP failure, I believe, has to do with issues relating to the delivered state of the Cambium products described below.
While these past few days of frustration can certainly be attributed to my unfamiliarity with the Cambium products, there are a few things I think Cambium could improve.
1) for whatever reason, all 4 devices were shipped with ancient Firmware (one doesn't expect several year old firmware to be shipped with supposedly new products) ... the 2 ePMPs were shipped with firmware that was so old that it predates cnMaestro ... which was why there was no reference to cnMaestro in the ePMP UI ... so ... first thing out of the box, these devices all need to be updated ... this firmware lag may also explain some of the issues I was having with the first e500 configurations.
2) even after the ePMPs were updated, they still did not link to cnMaestro ... it appears that cnMaestro is NOT a complete configuration tool which seems to be what is being advertised ... both the ePMPs had to be preset via their local UIs before they would onboard to cnMaestro
3) IMHO, based on many years of experience with both h/w and s/w dev, a 400+ page generic manual like the ePMP 3.5.1, that just describes buttons and entry fields for endless product variations with no relation to application is just an annoying waste of time ... as it turns out, the key detail I was missing had to do with the primary ePMP having to be set up as an ACCESS POINT first before it could function as a PTP Master (This is NOT INTUITIVE!) ... the SM has a PTP Slave as an option ... so ... why isn't PTP Master also an option under SM?
4) cnMaestro is also frustrating with respect to failed sync errors ... I still have no idea what I did to resolve the sync errors ... it took serveral hours of tweaking before they finally went away ... Sync Error Links specifically point to finding details on the failures in the EVENT screens ... I found the associated EVENT screens for these errors to be meaningless ... I suspect cnMaestro may be automatically building CLI scripts to update their products ... at a bare minimum, one would expect to be able to view these scripts plus be able to either step through line by line or reference the line that failed. The Event screens were expected to at least identify the parameter/feature that was being rejected.
With regards to the failed sync errors in cnMaestro: these refer to configuration sync. Devices can be resynced at a global level by navigating to Application -> Sync Configuration. This is the bottom icon on the left-hand menu. Then select the devices you wish to resync and click Sync Configuration. If there is an error in the configuration it should display here next to the device.
You can also sync configuration by clicking the Sync Configuraton link at the device level configuration page or by applying an AP Group to the device.
Configuration pushes are tracked under Application -> Jobs -> Configuration. You can click the Show More icon (clipboard) to view specific details for each device. This should also display the failure reason if there is one.
Where did you first encounter the failed sync error? We may need to improve the UX in that location to guide the user towards the above resolution steps.
All errors encountered from any page appeared to point to finding "MORE" details on the EVENT page ... the Events could be expanded and scrolled via left and right arrows ... however, I found the actual detail on these pages meaningless ... things like "failed to push configuration" can be open to interpretation ... why did it fail to push? Was the device unreachable (coms failure/offline/unplugged/power failure)?, Configuration parameter content error (too many, not enough, mismatch data type)? Configuration syntax error? etc. ... speaking for myself, if there is a config conflict, I like to be able to review the existing config against pending changes plus have a way to test a coms link before initiating an update/sync.
Thank you for your feedback. I've created a ticket to improve the configuration failure event by including the actual failure reason in the event itself.
Currently the failure reason can be viewed in the device level Details tab by hovering over the Failed status or in the configuration job details view: Application -> Jobs -> Configuration and then clicking on the job details button.
Here is a prime example of another unusual Sync issue ... (all firmware up to date):
2 x e500's on the same network using the same WLAN config ... one is wired to the router the other is linked via a backhaul ePMP pair ... all I did was change the SSID ... cnMaestro attempted to update both e500's and both devices reported failed sync ... manually looking at the device configurations, the wired e500 had its SSID updated the wireless one did not
attempted to restart the sync jobs several times with the same results ... I finally manually updated the SSID on the one that didn't update, then acknowledged the event ... it then sync'd properly
the other e500 has the following error "system_location:specified parameter greater then maximum length" ... even though the location is 3 letters and wasn't changed!
The way I finally removed this sync error was to manually clear all the locations both on cnMaestro as well as on the device UIs ... then did a sync ... then added back the location in cnMaestro ... still had an error so manually updated the device in error then a resync finally cleared ... there has to be a better way to fix these errors ... perhaps force cnMaestro to use the current device configuration? The error description in this case was incorrect ... the Location string didn't exceed the maximum 64 characters
Hi ,
This is a known issue in the device firmware and not an issue with cnMAestro .
It is already fixed in upcoming device firmware release 3.8
Regards,
KR.
Ok so yet another SYNC Error ... this time I set up a new WLAN linked it as a Guest Portal to the existing Vlan ... this was fine until I then changed the SSID Security from Open to WPA2 with a passkey ... Local UI shows both e500 devices received the security change BUT the local (wired) e500 is now out of sycn due to an invalid Gateway IP address 0.0.0.0 ... the gateway address wasn't changed plus both the Local UIs and cnMaestro show the correct Gateway address so this error is totally out to lunch and refuses to go away.
Hi bxdobs,
The incorrect Gateway occurs when the device reports 0.0.0.0 as the value and cnMaestro detects this and fails the configuration attempt. The goal is for cnMaestro to preserve the network settings based on what the device reports is already running and push the same settings in the full configuration file. You can correct this by forcing the value to refresh or manually entering the network settings as User-defined Overrides.
- Refresh the device by clicking the three-dot icon next to the device in the left-hand tree and click Refresh. Check the VLAN tab of the User-defined Overrides in the Configuration section at the device level view to verify the correct value was reported to cnMaestro. Rebooting the device would also force a refresh.
- Manually set the values by going to the VLAN tab of the User-defined Overrides in the Configuration section at the device level view. Uncheck "Auto-set from device". Check the Override boxes and set the network settings to what they should be for the device. If the AP Group already has the correct settings because they are not device-unique then you do not need to check the Override boxes and set device-specific values.
Yes thank-you ... spent over an hour with Cambium support on this issue ... the process to fix the sync error is straight forward ... prior to this sync error, everything was in sync and was working as expected ... the real issue is the Gateway value wasn't changed ... all I changed was the SSID Security from Open to WPA2 AES with a password ... when I Saved this configuration change the cnMaestro sync failed on one of the e500's ... as both e500's still have the correct gateway setting, it suggests cnMaestro messed up. Cambium support are investigating the log and configuration files.
Yes, it is expected that the gateway on the out of sync e500 would remain unchanged. cnMaestro detects that an invalid value is reported by the device and prevent the value from being applied back to it. This is an intermittent issue that can be resolved using either of the methods I mentioned above.
The most typical times I've seen this is for DHCP devices where it reports a gateway to cnMaestro as network settings are being applied from the DHCP server. So 0.0.0.0 is reported before the proper DHCP gateway value is populated throughout the device.
The flow for "Auto-set from device", which is enabled by default, is the following:
- Device sends its latest values to cnMaestro as part of a general refresh. This can be during registration or after cnMaestro detects that the device's configuration has been changed in any way.
- If "Auto-set from device" is enabled for the device cnMaestro will store the network settings reported by the device in our database to later be used in the configuration file pushed to the device during a configuration sync. This is the step that is causing failure. 0.0.0.0 is being reported by the device as the gateway.
- During a configuration sync a configuration file is compiled for the device using network values previously stored in the database. If 0.0.0.0 is set as the gateway the configuration sync will immediately fail.
The purpose of "Auto-set from device" is to preserve network settings used to connect to cnMaestro in order to prevent device disconnection. The most typical use case is if devices are using static IP addresses. This prevents having to set unique IP addresses for every single AP during onboarding as cnMaestro will automatically detect this.