What are the issues reported by the customers in 9.5.0.0.156 release?

Very sad

I experienced APs rebooting when getting 60-70 clients associated.

We were advised to downgrade to 9.4.3.12. No reboots now with 150+ associated to some APs

I didn't try 9.5.0.0.156 but 9.5.1.0.50 and had the same issue as Andrew. We downgraded to the same on advice from support and just upgraded to 9.4.3.0.16 which is working fine.

Not sure if it helps but;

I didn't try 9.5.0.0.156 but 9.5.1.0.50 and had the same issue as Andrew.

We have since downgraded to the same on advice from support and just upgraded to 9.4.3.0.16 which is working fine.

It does help. I was thinking of going to 9.5.1.0.50 I guess I'll have to wait.

I'm checking to see if we can ID the specific issue being described so we can give you a target fix.

Thanks Keith, that would be helpful.

We experience the same: ZF7363's are rebooting when the try to serve 50+ clients. We use version 9.5.1.0.5. In the logs it shows the last reboot reason: watchdog timeout or application reboot.

Hopefully 9.6 will solve the issues :)

Follow up:

I upgraded 9.5.0.0.156 last week and had to downgrade back to 9.4 due to the issue. I grabbed the logs from the a couple of the AP's that rebooted and the controllers if Ruckus is interested. Let me know and I can email or open a case again on the issue.

What I observed: Upgraded in the evening (9:00 p.m.?) and everything was great. No reboots overnight. At about 8:15 we started getting AP lost contact messages. It was random from site to site and I would bet that we never had more than 30 clients associated to one AP. At 8:45 a.m. I made the call after 7 different AP's rebooted to downgrade back to 9.4.3.0.16. Since the downgrade, I haven't lost an AP yet and it has been 6 days.

Now, I'm a K-8 school district and at about 8:00 a.m. is when we begin to ramp up for the day. But none of my schools are in session at that time and I wouldn't expect to see more than 300 clients across the entire org. The only thing that I can think that might be an issue, is that we aren't routed at each site but at the district level. This means that the broadcast for a single VLAN could have 1000+ clients (wired/wireless) depending on what network they are connected to (we are changing this over the next 13 months).

Sorry for the length, but the wireless is usually set it and forget it for us. I really want this to work as I'd like to start testing our new 7372 AP as a replacement to our 7363's for future purchases.

What we think is going on in these cases is a change to the way memory allocations in the AP were handled in 9.5. We have a workaround available (e.g. anyone needing to go to 9.5.1 for new AP model support as mentioned).

Please open a support case at https://support.ruckuswireless.com/ca... -- add any debug, logs, etc you might have so we can quickly ensure it's the same issue).

We're also working on a more transparent fix, but no ETA yet.

-K

Keith,

Done. Case ID: 00067398

I would like to know the workaround that is available.

Meanwhile we have an other open case (Case ID: 00064008). It could be related to this AP reboot problem, but I'm not sure. Currently it's not possible to retrieve the logs as the ZD is turned of :)

I would like to know if the issues in 9.5 are resolved in 9.6 or is the best option to downgrade to 9.4.3.0.16?

The issue described above is not fixed in 9.6.0.0.267. So the options are to downgrade to 9.4.3.0.16 or to open a case and work with the support engineer to tune the required parameters.

Other issues present in 9.5 are addressed in 9.6 - please refer to the 9.6 release notes for details.

-K