PMP450x Release 15.2.1 is now available

Any news about the "SM's in NAT" problem?

The problem seems to be NAT mode in SM's and the problem seems to be on the AP only.

downgrading the only AP to 15.1.1 and keep the SM's with 15.2 the problem seems to be solved.

I have collected CNUT files from 15.1.1 AP (450m), 15.2 AP )450m) and 15.2 SM (with NAT and PPPoE enabled).

This kind of problem is seen on 450m and 450 (i think 450i also)

See Warren Bricknell's post at this page

http://community.cambiumnetworks.com/t5/PMP-450/PMP450x-Release-15-2-is-now-available/td-p/90167/highlight/false/page/3

Thank you

I have collected CNUT files from AP with 15.2 and after 15.1.1 and SM with 15.2

1 Like

We are having a ton of issues with clients on 450b radios connected to a 450M AP dropping connection, sometimes the radio is reachable where the customer can't connect and sometimes it's the entire thing. Any guesses on what we have here?

450M AP --> 450B client, seperate management and NAT enabled. Both pulling IPs from DHCP.

Mat

Hello Matt,

Could you please tell us which software version you are using on 450m and 450b SMs? There was an issue similar to what you have described earlier in 15.1.X releases. This issue is now fixed in 15.2.1 and we recommend upgrading to 15.2.1 release.  It is also mentioned in the 15.2 release notes. 

Thanks
Dhaval

15.1.5

Matt,

Ok in that case please upgrade to latest release 15.2.1. 

This is a known issue in 15.1.5.

Dhaval


@Eric Ozrelic wrote:
We took a single sector with 30+ subs on it from 15.1.3 to 15.2.1 using cnMaestro in the cloud and everything went really well! All the SM’s auto updated to AES and then I just had to pop into the AP and set it to AES and everything was done! Thanks for adding this small but invaluable addition!

As a follow up to my original post... for those of you transitioning from DES to AES... sometimes it will take another reboot after setting to AES to get the clients to come back... my routine has been this:

1. Tell cnMaestro to update all SM's first and then AP with 15.2.1. Don't be worried if a bunch of SM's don't come back.

2. After the AP has been updated, and rebooted, it will be using NONE for security and will have a big red banner warning you that no encryption is being used. Set the AP to use AES, save and reboot.

3. Watch for your SM's to come back... if only a few come back or none at all... give the AP yet another reboot.

It's strange but some AP's just need an extra kick to get them to work properly with all the SM's set to AES.

1 Like

Okay updating to 15.2.1 I'll report back if I see the issue.

For the NAT problem i need to open a Support Ticket?

Maybe is solved in the 15.2.1? (i have 15.2 now)

Can you share more details on what you see with your NAT issue? I hope it's not in 15.2.1 as I just upgraded there.

SM's with NAT enabled have very slow internet.

Downgraded the only AP at 15.1.1 (and keep SM with 15.2) and the problem seems to be solved.

There're some details in the pages before


@Telemar wrote:

SM's with NAT enabled have very slow internet.

Downgraded the only AP at 15.1.1 (and keep SM with 15.2) and the problem seems to be solved.

There're some details in the pages before


There has to be a very specific NAT configuration because we're running 15.2.1 on both AP's and over 700 SM's  and we haven't had any complaints or reports from our clients regarding slow downs or other issues. We have a very vanilla NAT setup though. We share the NAT/WAN/MGMT all through a single shared IP. We don't use DMZ or port forwarding. We have the maximum number of NAT connections of 8192 enabled IIRC.

Looking at past comments, it appears as though this NAT issue may be triggered by one or more of the following:

- Jumbo frames (we're using normal/default MTU size on all radios)

- PPPoE (we're not using PPPoE anywhere)

- Using 450m AP's (we're using 450 and 450i's everywhere and have no issues)

The current temporarily resolution seems to be dropping the AP down to 15.1.X builds. SM's can stay at 15.2.X

Can anyone else elaborate further or update this list with configuration or system differences that might be worth noting?

1 Like

We're running into significant issues trying to upgrade our 430's from 15.1.5 to 15.2.1 using cnMaestro. Multiple 430 SM's have timed out and then fail to reconnect when the software update job is run. 

Hi jw1,
I’m just checking the obvious question first; have you seen this?
https://community.cambiumnetworks.com/t5/PMP-FAQ/15-2-AES-256-Encryption-FAQ/td-p/85930

If this is not the source of the problem, can you provide more details?
Model and SW load of the AP?
SW loads when the l;links were last good
Config file from one of more of the 430s (if you have them)

Reply directly to me if you’re not comfortable posting to all here

Bart

Hi, we're using 450i AP's and cnMaestro to do the upgrade. I've done 5 AP's with around 15-20 430 SM's on each AP, and each AP has ~2-4 SM's that fail to upgrade and become unreachable. A power cycle at the customer premise does not bring them back online. I've been using the 'Upgrade 5 in parallel' setting but selecting all of the SM's first then the AP in the job. I'm going to run through a couple AP's manually and see if I can get any 430's to error out and will send you details if I can replicate the issue.


Thanks, 

For further info I've seen my 430's become unavailable both after the first reboot after the "Writing File" stage, and also after the last reboot after the "boot image update OK. Resetting". At this point my only option is to upgrade cnMaestro and/or go back to using CNUT, this failure rate on the 430's is way too high.

For what it's worth, I have no issue updating to 1.6.3-r19 but I already had to roll back once from an upgrade to 1.6.3-r15 because our fresh, out of the box 450B High Gains on 15.1.4 were telling us "Invalid Onboarding-Key" during installation even though we do not use Onboarding Keys and have never used the feature. Prior to the cnMaestro upgrade they would on-board fine and we could follow our normal installation procedure with the cnArcher app. I opened a support ticket for this issue but support could only provide a workaround of enabling/disabling the feature for each individual SM rather than identifying the root cause of the issue. This wasn't a feasible or scalable option so I rolled back to 1.6.1-r10 because it's been the only stable combination of cnMaestro/cnArcher for us.

I've opened a ticket, even with CNUT I have 430's not coming back online. I just tried a CNUT update and 1 SM upgraded succesfully, 1 did not reconnect, and another just froze at 50% 'Programming' and sat there. After 20 minutes I logged into the SM to make sure it was still online and canceled the update from CNUT.

Just upgraded a 450i AP to 15.2.1 to test it out. I may be missing something obvious but I cannot seem to find the option to turn on encryption in the Security menu. It had previously been set to None. The unit region setup does not support AES-256 encryption but I had expected support for AES-128 as it previously supported DES encryption?


@lightnet-des wrote:

Just upgraded a 450i AP to 15.2.1 to test it out. I may be missing something obvious but I cannot seem to find the option to turn on encryption in the Security menu. It had previously been set to None. The unit region setup does not support AES-256 encryption but I had expected support for AES-128 as it previously supported DES encryption?


Hmm... that seems strange, do you see anything that looks like this? You won't be able to use AES-256 without a license key.

1 Like

Des - I think you may be using the "No Encryption" model hardware... this model specifically does not have any encryption capabilities, and is typically only sold to regions that require export control licensing in order to ship there.  It would be easy to tell this by sending me the model number of the equipment in question.

Ye , seems like I have the same issue. All my PMP450 , i and m Access points were running DES encryption before upgrading to version 15.2.1 but now has no encryption settings at all .. In fact ,  the "Airlink Security" section completely disapeared under the Security section.. I understand that DES encryption isn't that secure anymore but in my opinion it's a little irresponsible to leave us with no options at all.

I've includes the MSN , board number and MAC address below. 

5.4GHz MU-MIMO OFDM - Access Point - 0a-00-3e-60-44-f3

Board MSN :
M9UC0247XR9W
Board Model :
C050045A114A
C000045K100A
FPGA Version :
031576

-steph