Moving devices to different network


@Cambium_Rupam wrote:
You can select the cnPilot device and go to configuration page and change its network. If the cnPilot is connected to SM then it will follow its parent network hierarchy always.

Soon we are going to release Site feature where all the wifi device can be placed (even though they come through parent MAC once moved under a network->site it stays there)


Rupam

This is not always working I have several SM's that are not under their Parent AP, and I have no way to move them.

Also we have E400 radios that are not behind their SM and there is no way to move them to the correct location.

Also there is no way to Place AP's under a Backhaul link.  Logically the device tree should have BH Master-> BH Slave->AP's-> then SM's.

Having issues moving cnPilot R200P from the default network to a Customer Routers network using on-premise since the latest cnMaestro update. It worked fine before that. Now when trying to change the network under Configure>Devices I get an error message at the top that says "Can only move APs, PTPs or devices without a parent to a new tower or network."

Maestroerror_10-14-16.PNG

I was able to move 3 other ePMP devices without issue.

Are you cnPilot R200P devices directly connected to device not managed by your cnMaestro installation?

We are aware of issues moving devices that have parents not managed by cnMaestro and with WiFi devices being daisy chained together.  We are working toward solutions for both scenarios.

The device in question is behind an ePMP device. But again, this is the first time this issue has occured.

Checked the ePMP, which was onboarded in the original Maestro. Updated the onboarding information to on-premise and the cnPilot was automatically moved to be listed under the customer's SM. This function is new to me, but it gets the device out of the default network.

Thank you!

We have R201Ps connected to CSMs anf they just show up in a long list instead of showing up under the CSM that they are connected to.  Running 1.3.0-r7.  Is this fixed in a newer version of CnMaestro?

Yes, it should be fixed.

On the cloud server (version 1.5.1-r18) I can see that we have a R200 nested under an ePMP SM.

If upgrading does not fix this we can debug futher.  One important piece of information will be what version are your R201Ps running.

We upgraded CnMaestro to 1.5.1r8 

450i AP 15.1.1

450d SM 15.1.1 

R201P 4.2.3R4

~90% of the R201Ps are not treeing under their SMs.  Some of them are.  I tried deleting one, defaulting it.  Re-applying the profile and then adopting it but it still doesn't tree under the SM.  

Upgraded the R201P to 4.3.2-R4 (BTW, this is a PITA having to do it twice from the device itself) and it still isn't treeing under the SM it is connected to.  

I'll try defaulting/deleting it again and re-addopting it, but I think something else is wrong or I am doing something wrong.  

So when I look at the onboarding summary of one that it is treeing correctly, it shows the tower being set like:

Network: PN-MD
Tower: WTC
 
On one that isn't working, it looks like:
 
Network: PN-MD
Site
 
If I go to edit one that is working, it shows nothing in the drop down for site with options for "None" and other sites.
If I go to edit one that isn't working, it shows "None" in the drop down for the site with options for other sites.  
 
 
 

The R-series devices should report the SM it exists under when it registers to cnMaestro.  Are these devices that aren't nesting directly connected to their SM?

Please invite me to your account using the Invite Cambium Support button and let me know some of the problem R-series devices.  I will check what they are reporting as their parent device, if anything.  My support ID is jordan.stipati.

This is on-prem  Doesn't seem to have an invite cambium support option, or if it does, it isn't in the same place.  

They are dirrectly connected and powering their SMs.  

If you PM me a user/pass, I can add you as a user to look at it.  

Is there a way to check on the device if it is detecting that it is connecting to a SM?

How does the R201P know/detect that it is connected to a SM?

I've sent you a PM.  Check your messages.

I'll be able to check in cnMaestro what the device is reporting but I'm not sure how to check this on the device side.  I've sent a message to a developer on the device side to get more information on this.

Thanks for sharing access.

I checked your R201P and SM and the R201P has a blank string stored as its parent instead of the SM MAC address.  This indicates that either the device is not reporting a parent or cnMaestro is failing to store the value at some point. I checked the R201P device logs and didn't find any obvious issues.

I've sent some information to other developers to try and figure out why this is occuring.  I will follow up once I have more information.

Thanks.  Where can one see where the R201P stores the MAC address of its parent?

Edit:

I'm also confused as to how the R201P could know what SM it is connected to.  The SM knows whats connected to it because it has the MAC of the R201P in its bridging table, but the R201P shouldn't be able to see anything at layer2  but itself and the BNG at the other end of its QinQ circuit.   

 With this thought in mind, I deleted the SM and then re-approved it but this didn't change anything.  It did bring up another question.  When I reapproved it, it still had its location set which leads me to believe that its info wasn't truly deleted.  This is kind of an issue when reclaimed CSMs are redeployed to new subscribers.

You can view the parent MAC address in the Statistics view.  Click the Wireless icon (signal strength icon, second from the left), then click the Column Chooser icon on the far right.  Check the box next to Connected AP and click Apply.

The Connected AP column will show the MAC address of the parent as reported by the device.

Regarding the SM location, when latitude/longitude is set for PMP or ePMP devices, it is pushed to the device itself as configuration values.  These values are then read back in to cnMaestro to drive the UI.  When deleting and re-onboarding the device the same latitude/longitude would be read from the device, placing it in the same location.

In your redeployment scenario, during onboarding the latitude/longitude values can be set before Approving the device.  If the SM is not deleted from cnMaestro then the latitude/longitude should be set in the device configuration page.

In short, the device info is deleted from cnMaestro, but the name, latitude, and longitude values set in cnMaestro persist on the device itself.


@petecarlson wrote:

Is there a way to check on the device if it is detecting that it is connecting to a SM?

How does the R201P know/detect that it is connected to a SM?


A R201P's connected SM is not maintained on the device.  This information is sent to cnMaestro and is only stored there.

It is recommended to try reconnecting the R201P device to cnMaestro by disabling and then enabling remote management on the device.  Please let us know if this causes the device to correctly report its SM's parent MAC address.  The device should move under its SM if this fixes the issue.

No dice.  Tried it first without reboot, and then with a reboot after disabling and another reboot after enabling.  Still not showing up under the SM.   Anything else I can try?

Please enabled DEBUG level logging on the device, capture the logs while the device connects to cnMaestro and send them to me at jordan.stipati [.at.] cambiumnetworks.com

  1. Access device web-based UI
  2. In Administration -> cnMaestro disable Remote Management.
  3. In Administration -> Management set Syslog Level to DEBUG, ensure Syslog is enabled and Save.
  4. In Administration -> cnMaestro enable Remote Management.
  5. Wait for the device to connect to cnMaestro
  6. In Status -> Syslog Save the syslog to a file and email to me.

I will share this with one of our device developers to debug further.

The parent MAC address is determined using LLDP exchange, where the child requests the parent's info if a parent is present.