Adam Bates wrote: If I make any change in config, in my case I enabled management access via wirless, save changes, then the device is accessible via the management IP. When I plug it back in to the Netonix switch, everything has returned to normal.
Hi. Once the 2000 AP has had a config change made and saved, and once it's working properly with v3.5 - can that AP be downgraded and upgraded smoothly after that?
To be honest, I haven't tried yet. I will try this on Monday when we are back to full staff and post an update.
More to add. The problems I've had seem to be related to upgrades completed by cnMaestro on-premise. The condition does not appear when updating via the web UI...at least in the 2 that I've tried that way.
Hi Adam,
Thank you for your input.
We will check issue with upgrade through cnMaestro on premises.
Thank you.
i have updated about a dozen or so ap's to 3.5.
I use CNUT to udpate the AP's then i use cnMaestro to update theclients.
no issues so far.
I am rebooting the AP's prior to upgrade.
My upgrades have all been via web interface with a reboot just prior to running the upgrade. This resulted in success on the 1000’s and failure on the 2000’s.
So an issue with upgrading thru cn maestro or with netonix switch?
Was getting ready to upgrade a 2000 on a netonix switch this past week wsip switch 250dc i think? It's not on any separate vlans only vlans are to separate back haul from customer facing ap's
Is it possible 3.5 is not keeping your van settings when upgrading thus losing connection? What if you make the port on the netonix just a basic bridge port tied to your other customer facing ports does it still happen?
No, the VLAN settings remain in the AP, at least all the settings appear correct when accessing by the fallback IP. What is weird is that the AP MAC does not appear in the bridge/arp tables of the Netonix when the issue occurs. It does after I pull the device off the switch, power it up, save changes, and then put it back on the switch.
I don't know which device is the culprit at this point, the Cambium device or Netonix.
I just started a new batch of upgrades from cnMaestro. Is there anything else anyone would like me to check while I have an AP in an inaccessible status?
In response to a previous note, I have found that once a device is upgraded to 3.5, it can safely be rolled back to 3.4.1 and then back to 3.5 without the issue occurring again, even from cnMaestro.
I was hesitant to roll out this update based on the this thread but after slowing rolling it out to about 20 AP's with no issues I believe it to be stable and the issues that some are seeing must be isolated.
Based on previous issues I make it standard practice to upgrade the AP's prior to rolling out a firmware update.
I perform all my AP updates from CNUT and then I update all the clients from cnMaestro.
All my AP's upgraded with no issues and other than a few clients just needing to be restarted everything went smooth on there too.
Not sure if this applys to everyone, but we've found our problem.
After upgrade, if spanning tree (STP) is enabled on both the AP and the Netonix switch port, the AP reboots and STP starts discarding.
Disable STP on either the AP or the Netonix and the device is accessible.
So, Cambium. What changed in 3.5 with STP?
That is very interesting. We have STP turned on for all three of our 2000 AP ports (since some SMs are back-up conenctions for other backhauls).
We have been noticing what we thought was other oddities with STP in the past on SMs. We have three SMs that have STP turned on and any time they loose the wireless link for a reason other than an SM reboot, they will not re-connect to the AP until the SM is rebooted.
For example, SM is attached to an AP - both have STP on. The AP is rebooted after a firmware upgrade. The SM with STP turned on will never re-acquire that AP until the SM is rebooted. Then it conencts just fine - until the next time the AP is rebooted.
SMs without STP turned on have never experienced this. I hate to use STP on customer devices like this but there is a good case to have some SMs as a backup link for other backhauls - to give at least some connectivity until we can repair the main backhaul link.