PMP450x Release 16.0.1.1 is now available.

PMP450x Release 16.0.1.1 is now available. It can be downloaded at:

https://support.cambiumnetworks.com/files/pmp450/

1 Like

16.0.1.1 is bug fix release intended for customers who have PMP 430 SMs on their sectors and can't upgrade to 16.1. It includes the bug fixes found during the 16.1 release cycle. Notably:

  • Stuck in 100% CPU and not connecting to cnMaestro
  • 450i rebooting with "System Reset Exception -- Restarted by CaOs."
  • QoS configuration is not enforced in the uplink, when "Broadcast/Multicast Uplink Data Rate" is configured in "PPS"
  • Session_Status.xml crashing and having <td> HTML tag in it
  • And several other small fixes

If running 40 MHz, however please upgrade to 16.1 which has a uplink fix.

Any updates from those who have upgraded out in the wild? I always like to think no news is good news :)

I have not tested it very well because we have tried this version only on a 450m for a congested spatial frequency (10 users in the same spatial frequency that seems suffers slow connection) and SEEMS (I repeat seems) that this version solve that problem.

1 Like

Question:

This version solve the Restarted by Caos on 450i and i'm glad for that.

Can I ask the cause of that? Because I don't remember that "mortality" before this version and now many 450i's with 16.0.1 reboot cause restarted by caos.

Thanks!


@Telemar wrote:

Question:

This version solve the Restarted by Caos on 450i and i'm glad for that.

Can I ask the cause of that? Because I don't remember that "mortality" before this version and now many 450i's with 16.0.1 reboot cause restarted by caos.

Thanks!


Telemar,

Sure you can always ask. :) This "Restarted by CaOs" is actually a general reset case. So not all past (nor all future) resets from this message have the same root cause.

The fix that went into 16.0.1.1 for this was dealing with our internal messaging with the UGPS serial data and web interface interacting and using the same resource. With some more efficient coding, a mutex, and improved queuing, a fellow engineer got it fixed. It was a tough one dealing with both processors.

Sorry again for the trouble and glad you verified the fix! :) I continue to recommend 16.0.1.1 to all customers.

Charlie

4 Likes

Will this update allow SM's to be unlimited despite what the GUI says? (such as 4Mbps, 10 etc.)?

I am not sure I understand your question. This release will not change the behavior of the SM. If you're using a SM that is capped at 4 Mbps, it will continue to operate as a 4 Mbps SM after the software upgrade.

Okay, no news is still good news, but let me rephrase the question. Who has installed 16.0.1.1?

Me.

It solve the "reset due fatal error" issue in 450i connected with uGPS

I'm having issues with this version.

I recently applied this version to a tower we have with three 5g 450M, two 5g 450 and one 5g 450i.  6 OFDM AP's in all.

We were running a mix of 15.0.1-DES and 15.1.3-DES.  We want the increased uplink capacity with 450M in this later version so I just applied it to all the AP's at this site.  I upgraded the AP's first, and a few days later I upgraded the SM's.

First issue: After the upgrade(before and after the SM's were upgraded to v16.0.1.1), some SM's on 450M AP's are having the uplink power level drop (along with SNR) 10-20dB seemingly at random.  A reboot of the SM will usually fix the connection but not always.  Downlink power level and SNR are unaffected.  Previous to the AP upgrade there was no issue.  After upgrading the SM's to 16.0.1.1, the issue is still present.  One one AP, it's currently 10 sessions of 57 that are affected.  On another, it's 4 SM's of 57.  And 8 of 51 on the third 450M.  Our 450 + 450i AP's are unaffected.

We're running 30MHz channels and ABABAB frequency re-use.  All the 450m are on channel A and the others are on channel B.  

Is this a known bug in this version?  Without affecting our customer's by rebooting AP's over and over to test versions, is there a version that doesn't see this issue?

Second issue.  Boot bank.

One one of the standard 450 AP's I applied the new version to, the AP was on v15.0.1-DES - Boot Bank 0.

When the CNUT upgrade was done, v16.0.1.1 was on Boot Bank 1.  

A week later, I got a call from my tech office telling me, "No one will register to this AP".  I asked them to try rebooting with no success.  Later on, when I got to a PC to check, the AP had some "Fatal Error" in the Event Log and was running the previous 15.0.1-DES.  That's why no one would register, since all the SM's are now on v16.0.1.1.  ANOTHER reboot on the AP, then it booted up in Boot Bank 1 running the correct 16.0.1.1.  Then SM's registered fine.  It happened another time, booting itself intp Boot Bank 0, but this time it was an undesired power cycle from a power blip and ALL ap's rebooted. 

Is there a way to prevent the AP from reverting to the previous version? 

Or is there a way to lock in the desired Boot Bank upon next reboot?


@FVI wrote:

I'm having issues with this version.


Why are you using 16.0.1.1? I'd only be using this version if you're using legacy PMP430 SM's (you really shouldn't be using them with your 450m's anyway, it's a huge waste)... if you're not using them, then you really should be using 16.1 (which has been out for quite some time now and is very stable). The 16.0.x releases are a dead end. All new development going forward and any minor bug fixes in 16.0.1.1) are going to be applied to the 16.x line... and 16.2 is just around the corner, with a bunch of great features including support for auto contention slots on 450m. We use 16.1 on all of our PMP450's and have never experienced the issues you're reporting.

The only feature we needed was upload Mu-Mimo.  The other new features are nice, but didn't see a real NEED for them.  Since we have a lot of sites to upgrade, and I read that v16.1 leaves older versions behind, I wanted to get everything running with this version first, before advancing to 16.1.  In the past i've run into version mismatches that prevent registration (like v13.1.x long ago and recently DES/AES).

I assumed this version was stable, since there's another release after it (and multiple beta's after that) and didn't see many, if any negative reports about it.  Since our customer's dont have the patience to play with new/beta versions that have hidden bugs, neither do I.  If it's not broke, we don't fix it.

I'll have to try 16.1 in the middle of the night, and be ready to roll it back.  I'm not confident it will work as I didn't read anything in the 16.1 release notes that addresses the issue we had.

I have already rolled the 450M AP's back to 15.1.3 and we are back to normal, but still desire the uplink Mu-Mimo.

Any idea about the AP's Boot Bank, and if there's any control over it?

Seems stable, have it on 4 APs (450M) and few hundred clients.


@FVI wrote:

Second issue.  Boot bank.

One one of the standard 450 AP's I applied the new version to, the AP was on v15.0.1-DES - Boot Bank 0.

When the CNUT upgrade was done, v16.0.1.1 was on Boot Bank 1.  

A week later, I got a call from my tech office telling me, "No one will register to this AP".  I asked them to try rebooting with no success.  Later on, when I got to a PC to check, the AP had some "Fatal Error" in the Event Log and was running the previous 15.0.1-DES.  That's why no one would register, since all the SM's are now on v16.0.1.1.  ANOTHER reboot on the AP, then it booted up in Boot Bank 1 running the correct 16.0.1.1.  Then SM's registered fine.  It happened another time, booting itself intp Boot Bank 0, but this time it was an undesired power cycle from a power blip and ALL ap's rebooted. 

Is there a way to prevent the AP from reverting to the previous version? 

Or is there a way to lock in the desired Boot Bank upon next reboot?


FVI,

I have never heard of this issue before. I'm wondering if it's a hardware issue with the flash chip that can't fully program the software. We do have two banks of storage on 450 and after we flash one and verify the image, we flash the second bank. It sounds like this backup bank isn't finishing it's flashing. You should open a customer support ticket if the unit is still under warranty.

Also, in general we do not support nor encourage mixed versions beyond upgrading/downgrading. Almost all of our testing is units on the same release. We do over the air protocol improvements, and sometimes if SMs are on old versions they don't support it and have to move the sector to the old protocol and maybe can cause issues.

My recommended releases would be 15.1.5 (but had Stuck session issue with 450b), or 16.0.1.1.
Note that SM need to be on 15.2 or later to register to a 16.1 AP.

I'd recommend 16.1.1 but it has a bug where traffic to NAT SMs is not getting capped by MIR, which is fixed in 16.1.1.1, which is expected to be out early next week.

Charlie

As I asked in another thread, I’m curious if the issues you’re having is because you’re still using BAM… we’ll discuss in that other thread, but just wanted to post here as you linked here in case others come here too.