Sanity Check on my Unreliable WiFi: Do I Need More Access Points?

[big_spaceship]

TLDR: ZD1200 with 9 r710 APs covering 21K sq ft macOS-dominant biz, constant connection issues. Would more access points actually fix the problem?

Long form: I took over an existing enterprise network, consisting of an Untangle, 1Gb switches of various makes and models, and Ruckus for the wireless. The Ruckus consists of a ZoneDirector 1200 and 9 r710 Access Points, on a dedicated switch connect to the Untangle by 1Gb ethernet. The office is a rectangular 21,000 square foot space in a dense mixed-use urban area, with over 100 different wifi networks in range (I'm counting 2.4ghz and 5ghz separately here). We are a macOS-only shop with an average 100-150 devices on our primary wifi, and the same on our siloed guest wifi (total wireless device count rarely tops 300 devices). 

I get daily complaints about wireless not working. The most common issues are failing to connect after waking a laptop from sleep, AirPlay not working, and wifi appearing as connected but not transferring data. None of these are reliably fixed by toggling the antenna or restarting devices. 

Here are some of the more significant changes I've made in an attempt to reduce connection issues:

• Reduced channelization from 80MHz to 40MHz
• Reduced channelization from 40MHz to 20MHz
• Capped the maximum devices on any AP to 50
• Physically moved a couple of the APs to improve coverage
• Disabled the 2.4GHz spectrum on all APs except one for specific devices (did it by disabling WLAN service on the 802.11b/g/n radio)
• Modified every Mac's default connection preference to be the AP with the strongest signal, not the last AP accessed (which is the default)
• I added a script to the most afflicted computers, which keeps the antenna turned off for 5 seconds after waking from sleep
• Note: TX Power is configured to Auto, but all radios always run at Full power anyway

There are some other specific tweaks done for increasing compatibility with Apple products, but I've been working on this for over a year and I can't recall every detail. And as it's been over a year, the boss had demanded a permanent fix regardless of cost. That opens up my options in terms of adding access points or even switching to a different vendor. 

BUT: I have enough hardware on paper to completely control my airspace, and I don't think more access points will "solve" anything. If I succeed in fixing my network just by overpowering my neighbors, they'll be forced to do the same. I do not want a wifi arms race. 

Any suggestions?

[andrew_giancol1]

we're on a conference call now regarding Sticky clients. there is no predicting which AP a client will associate to. we've moved all over the store, and each time we're surprised and shocked by which AP we've been handed off to. This site we're reviewing uses Meraki MR66's. Sticky happens.

[michael_brado]

The decision to roam is made by the client radio drivers and supplicant... not the APs or controller.

We can only "help" them be less sticky by reducing power and supported data rates, such that we hope they will release and roam sooner.

[erin_mcclellen]

I suspect some of the solutions send a deauth or something to bump the client off in hopes that it will reconnect to something closer...

Also kind of bummed that Apple is being so crappy on the OS-X side - iOS supports 802.11r, 802.11k and seems to behave better. I remember when Android devices were the ultimate "sticky" clients.

I also yearn for the days when you'd see some desire by manufacturers to work with major vendors to iron issues like this out for everyone's benefit. But I think Apple is just running the clock out on OS-X until they have an 'iPad Pro Jumbo Laptop Edition' running iOS. 😞

[michael_brado]

Our Client Load Balancing solution, will not dissassociate anyone, but will ignore the first couple association requests if the AP is loaded and there are neighbor APs who have more capacity (when CLB is enabled).

[david_black_594]

What about smartroam?  It does what Bway NOC speculates - it disassociates the client when the RSSI reaches a threshold determined by the "smartroam factor" ranging from 0 (default) to 10 (0=disabled, 1=least aggressive, 10=most, recommended factor=3-5). I prefer raising the BSS min rate to 24 or sometimes higher to achieve smooth roaming.  Smartroam is a break before make connection whereas normal roaming is the opposite.  That's why I prefer raising the bss minrate.