The cnMaestro Cloud is updated with 16.0.0.1
I have been looking through the notes since 15.2 in regards to this issue,
CPY-14742 - "IPv4 data is blocked when configuration file is loaded on PMP450 SM with Protocol filtering enabled. To workaround this issue, select some filters randomly, in Configuration -> Protocol page, undo the changes, save and reboot the SM."
I have not been able to find any problem corrected entry for it in following versions, is this confirmed to work in 16.0.0.1? Also the IPV6 filtering was broken in the same way even before 15.2.
I set initial configurations via config file with protocol filtering so it is kind of important that this works.
@RK wrote:I have been looking through the notes since 15.2 in regards to this issue,
CPY-14742 - "IPv4 data is blocked when configuration file is loaded on PMP450 SM with Protocol filtering enabled. To workaround this issue, select some filters randomly, in Configuration -> Protocol page, undo the changes, save and reboot the SM."
I have not been able to find any problem corrected entry for it in following versions, is this confirmed to work in 16.0.0.1? Also the IPV6 filtering was broken in the same way even before 15.2.
I set initial configurations via config file with protocol filtering so it is kind of important that this works.
Hi RK,
I've checked the JIRA and it is marked as resolved (and digging further a route cause was found and fix applied).
So it should be good.
Subi should be able to provide more details if you needed as he fixed it.
best regards,
Andy.
Hello Dave,
is the CPY-15463 fix related to SM stuck in "connecting status" we sometimes face since years?
I opened this post: http://community.cambiumnetworks.com/t5/PMP-450/Pppoe-sometimes-stuck-in-connecting-state-after-connectivity/m-p/77704
SM session log shows this messages during those events:
Kind regards
Rocco
Has anyone seen any improvements in the frame utilization with this firmware on a PMP-450m (compared to 15.2.1)? We have a couple of PMP-450m APs in our network that appear to be reaching capacity and we are trying to understand if a firmware upgrade would be beneficial.
Nothing noticable. I happened to put it on one that reaches 90% utilization at peak and it's utilization graph looks unchanged.
Granted I only added the SMs for that unit to my initial test and updated them today so it's not exactly the most comprehensive test yet.
Will subs running 15.0.x code link to the medusas running this level?
@snorthway wrote:Will subs running 15.0.x code link to the medusas running this level?
They should do (I just ran 15.0.3 on 450 SM to 16.0.0.1 on 450m AP in the lab to check).
UL MU-MIMO will not work and it may bring down sector performance as a whole though, so not recommended in the long term.
If you have a more complicated setup with radius, QoS, AES etc there may be incompatibilities I haven't come across.
best regards,
Andy.
@mgonzales wrote:Has anyone seen any improvements in the frame utilization with this firmware on a PMP-450m (compared to 15.2.1)? We have a couple of PMP-450m APs in our network that appear to be reaching capacity and we are trying to understand if a firmware upgrade would be beneficial.
Hi mgonzales,
The frame utilisation in the DL will be similar to previous releases. This release has UL MU-MIMO so improvements will be seen in the UL direction. This can help with TCP traffic (as we can do the TCP ack for several SMs in one slot) and you could change the percentage DL setting in the configuration to a bigger number as the UL is now more efficient and shouldn't need as many slots.
Hope that's clear.
best regards,
Andy.
We are currently running 15.1.3 on everything. Is it safe to upgrade directly to 16.0.0.1?
@MosesTechNW wrote:
We are currently running 15.1.3 on everything. Is it safe to upgrade directly to 16.0.0.1?
Before you do so, I would recommend reading the upgrade notes for 15.2, as one of the major changes between 15.1.3 and 15.2 was the obsolescence of DES encryption, which is no longer available. If you have any devices using DES encryption (or are using encrypted links in general, just to be safe) you'll want to read the 15.2 AES 256 Encryption FAQ. I would also recommend reading the release notes for both 15.2 and 16.0 before upgrading for any other potential changes that may effect your particular configurations.
Other than that, interop between 15.1.3 and 16.0.0.1 should be fine, but the changes mentioned above will break your links, and need to be carefully planned.
Any news on 16.0.0.2 with the improvements that were mentioned elsewhere? Trying to avoid doing multiple updates to the network in short timeframe, and from what i heard a few nagging things were planned to fix in 16.0.0.2
2 Likes
Hi Guys,
Should i go from 15.2 straight to 16.0.0.1 or hold on. is there another update planned?
Paul
Paul,
There is a release coming up, 16.0.1. It includes all fixes in 16.0.0.1 and 16.0.0.2 (so far internal/private BETA, which will probably not be released publicly.) We anticipate it being out within about the next month. If you’re trying to limit upgrades, I would wait for that as it addresses some important issues in 16.0 and 16.0.0.1 which may impact your setup.
-Al
So, I read the earlier post regarding the security change. If I was to set my AP to a wireless security of (none) plain text prior to upgrading firmware, would that allow me to skip a firmware and go from 15.1.3 directly to 16.0.0.1. This would allow me to make sure that all SM's come back online with the latest firmware before setting the AP to AES security.
technically as soon as you upgrade to any of the newer firmwares the AP defaults to none if it was set to AES, you just get an annoying little red text at the top warning that it was disabled.... it avoids the need to reboot the ap 3 times (disable des, upgrade, reenable with aes)
Best bet is AP's first across the network then work on the SM's then once all SM's are on 15.2.1-16.x then swing on the AES on the AP's
2 Likes
Thank you
I have run into a bug on 16.0.0.1. We use 450sm's at some smaller sites as backups for backhauls. We just disable the ethernet port in the radios so if the PTP goes down, we can enable it in the SM and still get some traffic and network access to that site. When moving from 15.0.0.1 to 16.0.0.1 it creates a loop even though the port still shows "802.3 Link Disabled" in the GUI. That last few Aps that i upgraded, i just did not upgarde the SM that had the port disabled and had no issue. Not sure if anyone else does this type of setup but it is convenient for us.
I also just did a lab test. Once i am on 16.0.0.1, and i plug directly into the SM, I can't ping the SM but i can still ping the AP across the wireless.
1 Like
Hi JLoewen1,
Thanks for bringing this issue to our notice.
There are couple other customers who were running in to same issue, in the following thread.
We are looking in to this issue and will have a fix at the earliest.
Best Regards,
Balaji
1 Like
OK. Sorry. I must have missed that thread.