I solved this by changing the encryption options, choosing only AES instead of TKIP+AES in the Wlans configuration. He hasn't given me any more trouble since then.
we updated all macs to the latest os & then the rucus to the latest firmwares.
turned off 2.4 and now we can roam over 3 floors.
We found that sometimes the macs WILL NOT let go of a distant AP, they fight to maintain the shitty signal even if a new ap is closer, so you might be stuck tied to a 50% sig and there is a 97% sitting over u.
cleaning out all the stupid "remembered" connections in the mac control panel goes a long way to helping.
it seems more of an issue with badly placed wifi points.
Then you get the nonsense with "dual points" where the mac swaps between 2.4 & 5 depending on how it feels, seems swapping frequency AND AP does not cleanly maintain the connection.
then there is the issue of "sleep", if you are in a meeting room and tied to a WIFI & sleep, tehn come out of the room and relocate AP's... the mac just swallows packets, turning the wifi on/off fixes it.
oh and YES .. symbols in the names WILL affect the mac, mac follows the RFC exactly.
strange chars, may not pass the unicode values correctly "_-#[email protected]" etc
you will see the same with naming macs & DNS/ DHCP names.
I spent 4 months on this back it 2016, initially i was sorry I purchased ruckus, but then it sort of came together.
I got really angry with apple, becasue if you go to "sys-info" ->wifi
and make a note of the : (they stripped a lot of the info out....),
Card Type: AirPort Extreme (0x14E4, 0x134)
Firmware Version: Broadcom BCM43xx 1.0 (184.108.40.206.1a2)
you will find macs from EXACTLY the same family with specific revisions of the BC chipset
BUT with different FW versions!!!!!, ESP. if they are from different years of production.
when you update a mac it DOES NOT update everything at a system level, apple DOES NOT keep the internal FW's updated and in sync. (no FW is NOT available)
So you might have two 'identical' "MacBook Pro (Retina, 15-inch, Late 2013)"
but the damned BC FW is NOT the same!!!, how the hell can any system be reliable & stable , using such poor attitudes.
We.... me .. apple.. ruckus, identified a specific issue with sleep, where RCs was "closed out" due to time out, but since the mac was woken from sleep, it still considered the "link" to be alive..
we clearly saw packets going out from apple kit and disappearing into the "ether"
Much of this should have been fixed in later os updates of both sides.
Now my kit in factory location is fine over 3 floors of production area (110M long)& passes off nicely as long as it cannot see distant WIFI points it tied to previously & moved whilst sleeping.
but now users just toggle the wifi if it gets "stuck" (we have seen AP hand off stuck with other brands of kit as well)
as long as my mac does not sleep... i can freely wander about our sites and no handover issues.
and currently i have about 160 devices on WIFI... in this 1 location.
I think it is tolerated because:
1. the mix of devices is less legacy
2. Due to pixel masterbation... kit does not sleep so much.
All of our MacBook Pros are running High Sierra and working quite well, even with roaming. We are using the latest firmware with our vSZ controllers. Now, I say working quite well since end users are not complaining. We have a lot of MacBook Pros so I am assuming if they were not working well we would have heard end user complaints.
So I decided to do some more research and see if a similar issue has been reported to other wireless vendors. I came across this, which is quite old but the issue is very similar. I have made the suggested changes of scenario 1 on all three of our controllers and will see what happens when the users return from the holiday.https://community.cisco.com/t5/wireless-mobility-documents/apple-macbook-pro-dropping-wireless-connection/ta-p/3116976
I recently migrated from a single node vSZ to a two node cluster running 220.127.116.11.598. While working with support to get the licenses migrated we chatted about this issue. Two things came out of the conversation which I am in the process of implementing.
First, We switched from Proxy (controller) based RADIUS to AP based RADIUS. I had opted against this in our original deployment years ago because I did not want to create ~200 RADIUS Clients on each RADIUS server. Turns out, if all your APs are on the same subnet, you can specify that subnet CIDR as the IP and cover all APs in a single entry. Then you configure your WLANs to use an AP RADIUS auth method.
Secondly, 18.104.22.168.598 apparently has a known issue in which the RADIUS service restarts unexpectedly. This is supposedly resolved in 5.1.2. I am planning a maintenance window to perform this update after I let the AP auth changes settle.