PMP450x Release 15.2 is now available

This is only an issue if you have a device trying to send frames larger than 1700 bytes into a 450i or 450b device's Ethernet Port.   Those packets wouldn't be being passed anyways, so if you have a device doing this, the best thing to do would be to fix that device and stop it from doing this.  

We updated some logging and handling of these packets and when we see some regular arrival of those, it appears to be that logging and analysis is causing an issue in processing other packets for a tiny bit.   If they are regularly arriving, multiple times per second, it can have a larger impact.  Our analysis of the logs we have seen with this issue were showing some regular arrival of 1800+ byte length packets.

We will address this in 16.0, but the important thing to note regarding Jumbo Frames, is that we only support up to 1700 byte packets, so anything larger than that would be dropped anyways.  It is safe to use frames up to 1700 byte length even with this issue in place for larger packets.

3 Likes

Enable or Disable Max Tx Power not work.

I change Disable Max Tx Power but power 22.

In version 15.1.3 after change it is parameters power changed.

after upgrading a 450m AP and all the SMs attached to that AP via cnMaestro the SMs now display the following red warning at the top of the SM page:

"The encryption setting configured prior to upgrade is no longer supported, radio links are not encrypted.
Apply a supported encryption configuration under Configuration->Security->Airlink Security->Encryption Setting and reboot to remove the above warning."

is ther a way to change this without touching and rebooting every SM?!?!

It’s in the release notes they discontinued DES you have to swap sms to AES once their all changed then enable aes on AP


Or just disable encryption either way your gonna have to reboot sm… that said it’s in the patch notes pretty extensively

yeah i read the notes that said encryption went away but the notes didn't explain that you'd then need to touch and reboot every dang AP and SM after upgrading. :-/

my question is "do i have to touch and reboot every device?"

why doesn't the updater just apply this change?!?!

1 Like

Your not wrong, as I personally think the SM should just always be set to AES after upgraded to 15.2 and rebooted, as the SM will connect regardless of it's setting if the AP is set to PT and the SM is set to AES it connects... So why does it make sense to leave the SM on the defunct-DES setting which is operating as PT.

The drop-down can literally go away just make the radio AutoSelect AES/PT based on the AP it connects to as it already does, instead of booting up in defunct-des which technically is PT. 

With DES gone the whole reason for having the setting is now useless, it's either AES128 or the ap has AES256 and it uses that instead to my knowledge, and theirs 0 performance impact so shouldn't the basic setting just be AES

1 Like

I'd like to say that I'm also disappointed in how Cambium handled the whole DES to AES conversion... it just makes sense that if you upgrade to 15.2 it should automatically set the SM's and then the AP's to AES. It's going to be so much work and additional downtime for us to convert. I'm really dreading moving to 15.2 and beyond because of this.

We are looking into this now... as well as potential solutions for having to touch everything.  Keep an eye on this thread for updates.

1 Like

thanks Matt, I really don't want to reboot everything twice just to do an upgrade. plus there's no way to easily ensure that everything was updated AND set to the right settings.

-sean

What does this mean for a 430 series SM that is connected to a 450series AP?  Will the 430 series SM no longer connect as it doesn't have the option of AES? will 15.2 give it this option? or am I forced to stay on older firmware from this point till I can afford to swap out 500+ SMs to 450 series?

Trust me, we are working to update all legacy equipment, but this is far from happening overnight and likely not within the year.

1 Like

You can do it but you’d have to leave the AP on plaintext and not run encryption for the 430 connected APs

Isn’t much worse than DES as DES isn’t considered secure since a while

After upgrading to 15.2, we recived multiple complaints from end-users stating that some websites would not load or took very long to load, some even had issues getting to O365. This only appeared apparnet on SMs running as routers with the pppoe client enabled. We then rolled back all APs to the previous version but kept all SMs on 15.2 and this resolved all issues and internet performace returned to normal.

Any Idaes?

We have not seen this behavior at all... I will ask if this can be replicated somehow.  If possible, should this occur again (or if you're willing to try to go to 15.2 on the AP again), can you send a CNUT capture to us?

This may be related to that MTU issue mentioned earlier. Our sites are connected to a fibre ME network running jumbo frames.

Hi,

we observed low performance too.

This happened with AP 450, 450i upgraded to 15.2, NOT with 450m.
Some customers notice a almost zero donwload or decreasing performance over the time.

Downgrading to 15.1.5 (leaving SM to 15.2) on the AP everithing was fine. With a particular customer using our connection to streaming video the problem is easy to note (see image). It was always a perfect download until we upgrade his AP (450i), as you can see in the screenshot. We solved this issue going back to 15.1.5 for all our AP 450, 450i (90).

2 Likes

We upgraded all the APs (12 total) at a tower to 15.2 in order to switch from using Canopy Sync to Cambium Sync.  That part went fine.

But I notice in the Sessions list we are getting a bunch of IDLE sessions in red with no customer name, just the LUID.  These SMs are active on an adjacent sector, but I have never seen this behavior before, where IDLE sessions only have the LUID, not a customer name.  Except occasionally with a very marginal link that can't complete registration.

We haven't been upgrading the SMs to 15.2 yet, kind of scared about the whole AES/DES fiasco.  We do still have some 430 SMs.  We are running with no encryption.  But the encryption issue and the 430 SMs seem unrelated to the strange IDLE sessions with no customer name.

Do you have the sms set with alternate color codes maybe during reboot they roamed to that sector and then roamed back to the other sector when it was rebooted

The session list is now a bit better as they maintain Luids and offline time as a side effect if you have multicolorcode sms their a bit more visible than they were on the AP before.

the keeping luids persistent is a change that takes some getting used to but then it’s a bit more consistent

2 Likes

@Ken Hohhof wrote:

We upgraded all the APs (12 total) at a tower to 15.2 in order to switch from using Canopy Sync to Cambium Sync.  That part went fine.


Curious, why did you specifcally want to switch from Canopy to Cambium sync? Benefits?

In my experience, Canopy sync is causing constant SM disconnects on 450i / 450m APs running 15.1.3 or higher so that might be the reason. Cambium sync resolves the issue...

Thanks, CSup. What you said about the LUID persistence is likely what is being seen here.

Many customers had asked for a change such that when an AP is rebooted, the LUIDs given to registering SMs be persistent across reboots, and this was introduced in 15.2. If you no longer want to see those, you can press the “Clear Idle Sessions” button on the AP and they’ll go away.