Yes. This release is for PMP/PTP 450/450i/450m/450b, both CBRS and non-CBRS bands.
- The cnMaestro On-Premises version 2.4.1 supports 20.0, in general.
- There are no plans, as of now, to support enhanced frame utilization feature on 450m. We might consider it in future.
CPY-16965: 450b SM in NAT mode, with VPN end point on it’s LAN, stops passing traffic when NAT table entry > 1500
The end customer has a VPN client below a 450b SM in NAT mode.
In this customers case, the traffic stops passing when there were more than 1500 entries in the NAT Table.
It was seen on 16.2.3. We have not replicated this issue in our labs. We are still investigating this issue.
The workaround is to configure the SM in bridge mode.
CPY-16820: 5 GHz 450m looses management access every few hours.
When AP is in this state, SMs will loose connectivity. Rebooting the AP will fix the issue.
This issue was reported on 16.0.1.1 and 16.2.2.
We are still investigating the issue.
If anyone is seeing these issues, please report to us by opening a customer support ticket
Are there any issues with downgrading from this latest v20 release? Say if we wanted to go back to 16.1.1.1
If you are on 20.0 and have configured “HTTPS only” for web access, you will not be able to downgrade from 20.0.
This is because of mismatch in TLS versions used by CNUT and radios running 20.0.
The workaround is to configure “HTTP only” or “HTTP and HTTPS” for web access.
We are working on getting a new CNUT version released.
2 Likes
Are there plans to add IMM to 450m? If so, what is the planned timeline?
We are actively working on adding IMM to 450m.
I do not have an ETA at this time.
1 Like
Enable Max TX power on the SM’s doesn’t appear to work. Setting this value appears to have no effect, even after a reboot.
Upgraded 2 450i 900 OMNI APs, each currently with 3 subs. Under 16.2 the first AP was running running 8X MIMOB and 6X MIMOB with one marginal.sub at 4.8 miles running through a lot of trees with a RSL of -78. Seeing some improvement in the stability of the marginal sub and it seems to be holding a solid 4X MIMOB. Previously it was about 70 percent 4X MIMOB with drops to 2X MIMOB.
The other AP was pretty solid with 8X and 6X MIMOB, but now seeing some weirdness with one sub It is actually closest to the tower with a -60 RSL with medium tree coverage. It was originally a solid 8X MIMO B but after the upgrade it began scaling up and down, going from 1X MIMOA up to 6X MIMO B hitting about every modulation rate along the way. Once at 6X it would suddenly drop back to 1X MIMO A and start the process over. After about 30 minutes, it appears to have stabilized. Currently running 7X MIMO B. The other 2 subs were solid during this process. Had some rain and cold fronts coming through so maybe some weird weather phenomenon.
We’re seeing the most benefit from the new modulation rates on the uplink. Omni’s suck for interference and the new offset rates are showing up across most of the uplinks.
Waiting for people to wake up and put things under load. The initial impression is we like what we see.
Rolling back to 16.2. Both AP randomly dropping SM registration for no apparent reason. Registration drops range from about 30 seconds to 20+ minutes. Happening on both AP’s and getting worse under prime time load. Registration was rock solid before the upgrade. No indications of any type of sync issue.
AP reboots do not seem to assist in SM recovery, but we did test one instance on an SM that had not registered after 10 minutes and it came right back up after a hard reboot for what that’s worth.
Seeing this in the AP’s SM Session Log which seems to kick of the event.
11/22/2020 : 19:22:33 CST : Event: SMSESFAIL, MsgType: SMVCERR, NewState: OOSERVICE, Flag 195
The SM Logs generate a lot of repeating messages.
11/22/2020 : 19:25:39 CST : Event: SES_MSG, MsgType: PAREQ, NewState: IN SESSION, Flag 0
repeated 18 times
11/22/2020 : 19:25:32 CST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
11/22/2020 : 19:25:32 CST : Event: SMSESINS, NewState: REGISTERED, Flag 21
11/22/2020 : 19:25:32 CST : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
11/22/2020 : 19:22:33 CST : Event: AUTHEN_RESET, NewState: IDLE, Flag 0
11/22/2020 : 19:25:32 CST : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0
11/22/2020 : 19:25:32 CST : Event: AUTHEN_SUC, NewState: AUTHENTICATED, Flag 0
Issue is occuring as I’m typing this. Will have to ride it through and roll back in the wee hours.
I broke my cardinal rule about never trying the latest and greatest!
1 Like
Hi,
We have seen a number of 5Ghz 450b Mid Gain and 450b High Gain units with Bandwidth PLL lock lost issues. If we downgrade to 16.2 the issue goes away (only connects at 2x MIMO due to AP on 20). These units are connected to 450m APs upgraded to release 20. No 450 units affected yet, and seems like the first version style 450b subscriber units (not the newer style ones). Random on the 450b High Gain units though. These units worked fine with no issues on 16.2 release.
1 Like
@arobo thanks for posting. Would you please email me the engineering.cgi on all the SMs that had this Bandwidth PLL Lock Lost issue? Even if they’ve already been downgraded, their might be some info in the Event Logs. There seems to be some hardware dependency on this issue and your help would be greatly appreciated.
16 hours after rolling back to 16.2.3 and not a single rereg event.
1 Like
Anyone have tried this version on a 450i AP? Hown much is the improvement with the Increased Packet per Second?
Hi, I have sent them via email for you. 
Hopefully will be of some help
1 Like
Hi Everyone,
Due to the reported issues of Bandwidth PLL Lock Lost errors on 450b with Release 20.0, we have decided to pull back the release from distribution while we investigate the issue. The issue presents itself as the 450b SM’s not reconnecting to the AP after they have been upgraded to 20.0. This appears to only be affecting systems with 450b SM’s, but we recommend not using 20.0until further notice.
If this issue happens, the 450b will likely need to be manually downgraded to an earlier release, as it is not something that is recovered via a reboot. It looks to only be affecting certain 450b SM’s, and we are investigating that as well, to see if we can find a correlation for affected devices.
If you have any devices experiencing this problem, please contact support.
To know if this issue is happening, on the SM GUI, you will see this message in Red at the top of every page:
Bandwidth PLL lock lost
Also, in the event log of the SM’s, you will see this message, indicating that the SM is not seeing any radio energy while scanning for the AP:
Radio not receiving any power.
Recovering radio that is not receiving any power.
Forced reset;
We will be in touch as we ready an update to address this problem, and apologize for the inconvenience if you have been impacted by this issue as you used 20.0. We will also look at the other reported issues mentioned in this thread.
Regards,
Aaron
1 Like
We were seeing lots of issues, session drops, on our 900 APs in high noise. Rolled back too 16.2.3 now.
1 Like
Yeah, we experienced that too with 900 and also some 2.4GHz… seems to have something to do with noise and/or multipathing issues. Rolling back to 16.2.3 cleaned up everything.
1 Like
We haven’t run into much issues with the 20 release except with one instance of “PLL lock lost” once this morning with a 450b to a 450m. In the scenario we ran into that was with 20 firmware was trying to connect to a 16.1 release. The installer swapped it out with a different firmware horn before I could get any information.
So far all of the 4 AP/CPE’s that were fully upgraded seem to be working normally, but we have stopped rolling it further.
We have resolved the “Bandwidth PLL Lock Lost” problem on 450b and also a 20.0 session drop issue.
Much thanks to @Eric_Ozrelic for help in debugging the issue. 20.0.1 is now running very well on Eric’s troubled setups.
If anyone else would try 20.0.1 beta it is available now:
https://community.cambiumnetworks.com/t/pmp450x-software-release-20-0-1-beta-2-is-now-available/74729
If you find any issues, please let us know ASAP as we are aiming to release it soon.
I highly recommend anyone running 20.0 upgrade to 20.0.1.
2 Likes