There has been a lot of chaos on Catalina MacOS and its interaction with networks that have deployed Ruckus products for wireless service. Issues are being seen in current Catalina MacOS that did not appear in earlier releases of MacOS: Mojave, High-Sierra, etc.
TAC managers have asked that we share information with our customers.
It is recommended that Macbook users use 10.15.4 who wish to use Catalina OS or have got an relatively older version of Catalina MacOS: namely 10.15, 10.15.1, 10.15.2 or 10.15.3. Apple has fixed a variety of bugs including but not limited to Wi-Fi, Safari stop responding when attempting to use Apple Pay, HSTS enhancement etc.
Apple has released beta version of 10.15.5 and it will soon be available officially on their website.
Some of the useful URLs on issues encountered with Catalino OS are:
“Apple first announced that it would ultimately wind down support for 32-bit apps more than a year and a half ago, when it began pushing alerts to macOS High Sierra users that 32-bit software was “unsupported.” The apps still worked, but with Catalina’s official unveiling back in June at WWDC, Apple made the eventual discontinuation official. With the launch of Catalina, 32-bit apps no longer function.”
It would be best
if you can open a TAC ticket with Ruckus to investigate this further, since it requires debug on a packet level and it would be best to keep this all logs documented on a case. Until unless we debug this issue we would not be able to identify the Root cause.
For less than the cost of a support contract, we dumped in a few UBNT APs and resolved the problem.
I spent a TON of time (free labor for Ruckus!) digging through the client side logs. If your users are flexible, I suggest doing two things to improve the wifi experience on Catalina:
- Disable bluetooth (or in our case we found, simply don't use BT if enabled) - Disable Airdrop (more specifically, AWDL)
I strongly suspect that there are bugs on both sides happening here. Ruckus side is a big unknown since there's not much public discussion of the issue. On the Mac side, it's worth looking at what AWDL is and how it works. Airdrop and other services like it (Airplay, what else?) use a local ad-hoc wifi network for data transfer. The OS "seamlessly" flips the wifi chip between two channels (your real wifi connection and the airwhatever device) to sort of "multiplex" two wifi connections in one. This generally doesn't break things, but it does mean that the radio IS off-channel for the main wifi at times, and I'm guessing this is where things get screwy.
Anecdotally, our problem users had far fewer problems if they just stopped using their airpods (yes, BT is on 2GHz, and this site is 5GHz only, but it's a shared radio and who knows what Apple is doing here). Same w/disabling AWDL (assuming they got the instructions right).
But the AP swap has gone really well - we went from guys on Zoom all day having drops every 5-10 minutes to going a full day without a single drop that they noticed. I hate UBNT stuff, but we had some spares so we gave it a shot... I suspect they simply have more customers than Ruckus that have a large Mac population. I think Ruckus is so entrenched in the enterprise market that they still think of Mac/ios as "fringe" and just don't put resources into it.
Hey Bway NOC... this is a VERY insightful find. It's interesting to me that AWDL uses similar techniques for 'off channel' scanning to what Ruckus "Channel Fly" uses for interference discovery, channel & power selection decisions. I'm due on another remote support session with a senior Ruckus engineer (about this and a Bonjour Fencing failure) in 3 minutes time... and I will raise this with him.
We're seeing this happen more with slightly older MacBook pros. Our 2017 and newer ones seem stable whereas the 2016 and older ones keep falling off the network. This is a small network of Wave 2 APs running current firmware.
Has anyone looked at this with the Big Sur previews?