Could you please get this added to the cloud version of cnMaestro? Thanks!
I'm sorry about that. It will be available on the cloud shortly.
1 Like
Is there a plan to fix the "Ethernet TX Stalled" error problem which occurs on SMs running 15.2, in NAT mode, connecting to Medusa APs? It wasn't mentioned in the release notes, but this is a serious issue.
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!
6 Likes
HI Darren,
We are still investigating this. It was not addressed in 15.2.1 and I can't promise at this point that it will be for 16.0 but will keep you updated.
1 Like
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
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.