PMP450x SM & PTP450x BHS which supports both DES and AES, but currently running DES, will be automatically configured to AES after upgrading to 15.2.1.
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!
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.
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.
@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.
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?
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.
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
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.