PMP450x Release 20.0.1 is now available

Products PMP
21

Thanks, we have not seen a repeat and it eventually cleared from the SM list on its own.

22

@ahults Thanks for posting. What version of cnMaestro On-Premises were you using? Did you upgrade your on-prem software and did it resolve?
I know for 16.2.1 and later 2.3.0 of cnMaestro on-premises is required. But sounds like there maybe is another incompatibility with 20.0? I’d like to know so we can document it. @tyc said 2.3.0r28 or later resolved it for him.

23

We were running 2.4.1-r10 On-Premises after updating to 2.4.2 the onboarding problem went away. I am thinking it was a compatibility issue with 20.0.1 and 2.4.1-r10.

1 Like
24

@Riverrat, thanks for posting, that is strange. Looks like something in our local database wasn’t isn’t right. Did you happen to grab a support/cnMaestro capture while it was happening? Do you recognize the other MAC address? As you only expect one “Hudson” SM? Or you expect the second Hudson SM, but it was unplugged but still showing up in the list?

And note if SM tries to register and the AP already thinks it is connected, then it is recorded from the AP as a “Reregistration” and the registration process starts again. So I don’t expect there would be an issue if the SM came back.

25

Does CNUT no longer work with v20.x?

26

It works just fine… make sure you update to the newest revision.

27

Charlie,

No on the support file. Should have grabbed it but it really wasn’t causing any real problem. The 2nd “Hudson” had been used as a test rig and was only linked for a few minutes and it was a couple of hours later when we noticed it was still the SM list. As noted, it eventually cleared on its own.

28

I just wanted to confirm whether or not there were any changes to timing with this release. Can anyone comment on whether this would cause interference with any sites running 16.2.1? I’m apt to think there wasn’t any timing changes, since v16.2.X can connect to v20 AP’s (granted, at 2x).
Anyway, if someone could comment on that, I will know whether or not to roll it out on a single site or not.

Thanks!

29

Long shot but anyone tried 20.0.0.1 on network with a Rajant Kinetic Mesh?

I attempted this upgrade starting with the SMs. After SMs were done, everything looked good. Attempted the AP and which came back online but then Rajant Mesh segment of the network went crazy. Looks like Rajant systems were struggling to to keep the best path. Nodes were dropping constantly and none of the main towers would take over as the master.

I could not see any issues with the Cambium AP or SM units but the Rajant systems was in a storm like state.

Rolling the AP back to 16.2.3.1 settled things down so not sure what changed in the new firmware but our Rajant Mesh segment of the network wasn’t happy.

Additional info, we have 7 towers.

  1. Fibre connected switch that provides lan access to one Rajant LX5, CMM5 and 450i AP
  2. Fibre connected switch that provides lan access to one Rajant LX5 (Primary Backup Master)
  3. 450i SM providing network access from AP to switch, LX5 (Configured to be master as it is most central)
    4-7. 450i SM providing network access from AP to switch with LX5 (Mesh repeater and secondary backup master)
30

Just did mass update for all of our cambium units. For some reason, on older 450 SMs, we’ll occasionally get the unit basically factory defaulting and connecting to the AP via ICC. I’ve gone in and re-setup the units after this and they’ll connect again, but shortly after will drop offline again until we have a technician go out and either replace the radio or go through CNArcher again. Just curious if anyone else has been having issues with older units.

31

Has anyone had any SMs get defaulted after the latest 20.0.1 update? We’ve had a few (out of thousands) do this, all seem to be older SMs. Some of them were already on 20.0, some were on 16.2.3 before being upated.

Update: (this is the same Company as Trevor)

32

We just updated few thousands SMs, and we didn’t had this issue.
How did you updated them? cnMaestro? CNUT?

33

There are no timing changes between 16.x and R20.

1 Like
34

Has anyone tested it on PTP450 links?

35

Yeah we have it running on a 450b CBRS PTP link with out issue

36

No issues with a 5Ghz PTP450b link.

37

Hello,

no issue on my side too with the PMP 450i in 5 GHz.

Sincerely yours,

Olympe Niragira

38

On 16.x PTP450 links this worked to get upload frame utilization:

snmpbulkwalk -v2c -c Canopy -m ALL 169.254.1.1 .1.3.6.1.4.1.161.19.3.1.12.1.2

.1 was download and .2 upload on master. No longer works on PTP450 links running 20.0.1. Any ideas?

39

We updated them using cnMaestro for all.
out of a few thousand, only had about 6 get defaulted, and all were older SMs (not 450b)

40

In 16.x and earlier SW, the Total Frame Utlization on Master is available from OID “frUtlLowTotalDownlinkUtilization” ( .1.3.6.1.4.1.161.19.3.1.12.1.1).
But, the Total Frame Utlization on Slave is available from OID “frUtlLowTotalUplinkUtilization” ( .1.3.6.1.4.1.161.19.3.1.12.1.2).
This behavior is changed in 20.x SW, where the Total Frame Utlization on both Master and Slave is available from OID “frUtlLowTotalDownlinkUtilization” ( .1.3.6.1.4.1.161.19.3.1.12.1.1).

Please note that in Point-to-Point case, Master and Slave schedule Tx data independent of each other.
A PTP Radio will have Frame Utilization data only in the direction in which it is transmitting.
You have to query both Master and Slave to get Frame Utilization data in both the directions.

Whereas in the case of Point-to-Multipoint, AP schedules the Tx and Rx data, for the entire sector.
So, AP is aware of the Frame Utilization in both Downlink and Uplink directions.
You just have to query the AP to get the Frame Utilization data in both the directions.

1 Like