Skip to main content

7 Messages

 • 

170 Points

Fri, Jun 14, 2013 12:13 AM

Closed

Doesn't need answer

Apple Device Roaming

I am having a problem with frequent disconnects on apple devices when signal strength is great. In looking into this further, I noticed that the apple devices in question are roaming at an alarming rate. This is happening across iPad, iPod, and MacBook platforms. For example, I looked at an apartment with an iPod touch that was roaming every 30 seconds or so. There is a Win7 laptop in the same apartment that has not roamed one time. I have about 40 Apple devices on the network and similar behavior is happening on 70% of them. I have about 40 other devices on the network and this is not happening with any of them that I have looked at so far. What is more, the Apple devices are roaming out from a nearby AP to an AP several hundred feet away with a few buildings between them. The user is not leaving the apartment but the device is roaming to APs throughout the campus, even APs it either should not see at all, or just barely.

Any ideas? Has anyone seen anything like this before?

Responses

43 Messages

 • 

844 Points

7 years ago

Hello Jeremy,

With reference to your post, roaming is always a client decision and never an AP's, do you have channelfly enabled on the ZD? What is the version of firmware on the ZD?
Also are the devices roaming on the 2.4 GHz spectrum of frequency or on the 5 GHz, there might be interference being experienced by the AP that us causing the devices to roam .
Also kindly enable 802.11d under the Advanced Option of the WLAN that these devices are connecting to, we have seen that Apple devices sometimes default to the lowest available speeds when this feature is not enabled.

Also I would recommend you contact Ruckus Support for further investigation of this issue as the support info file of an AP gives valuable information regarding client statistics.

Hope this helps.All the best.

3 Messages

 • 

270 Points

7 years ago

I had a similar issue with apple devices recently, and here is what was going on. the apple devices typically use a 5GHz radio, and if the channelization is set to Auto, then they can't make up their minds. fix the channelization to 20MHz (I would do it for both 2.4 & 5GHz radios) and the problem should go away.

43 Messages

 • 

844 Points

7 years ago

Valuable input Greg.. :-)

16 Messages

 • 

214 Points

7 years ago

I've had the same problem. This appears to affect OSX 10.7 and later. I have one system still running OSX 10.6 that stays connected (probably not a 5G connection). I can replicate the problem quickly by spinning up an HD Skype call or Google Hangout with another client and within minutes the Macbook disconnects from the wireless network (even though it's still available).

I've been working with Ruckus support for over well a month now on this issue with no resolution...we've gone through all the settings, dropped the environment down to a single AP, RMA'd the APs, spun up a new SSID, set the channels statically, etc... My Apple devices still disconnect and don't reconnect!. Even though the SSID remains available, the Macbooks don't rejoin the network without manual intervention (simply selecting the SSID to join will _immediately_ reconnect the Macbook to the network).

I was hopeful that Greg's recommendation above (set static to 20 MHz) would be the magic bullet but I can still see and replicate the issue.

Any other suggestions out there?

129 Messages

 • 

1.6K Points

IT Scott: Any resolutions that "fixed" your OSX and iOS disconnect wifi problems?

16 Messages

 • 

214 Points

We patched to 9.6.0 and made some changes to set the mgmt-tx-rate to 6Mbps by adjusting "ofdm-only" and "bss-minrate". That has helped - I'm still seeing disconnects but they're less frequent and more evenly distributed across the clients (Mac vs. PC).

9.6.1 is now out so that's my next order of business to try to get this fully resolved.

129 Messages

 • 

1.6K Points

Thanks. We are running 9.6.1.0 build 15 "...no joy in Mudville..."

16 Messages

 • 

214 Points

Nor here, RiX. The smart-roam option below didn't seem to help either.

129 Messages

 • 

1.6K Points

Anyone with roaming issues try: 9.7.0.0.220 ?

Any good results?

3 Messages

 • 

270 Points

7 years ago

unfortunately that initial fix didn't work for more than a few days for me. after that I turned the 5GHz radio off, and that resolved the symptoms that the users were experiencing, but obviously did not "fix" the problem. what seems to have finally fixed the problem was upgrading my firmware to the latest version 9.5.2.0.15 (I believe). check with tech support for the firmware upgrade path from your version, because if you skip an intermediate upgrade you will have problems. I upgraded the firmware on 7/17/2013 and have been running the 5GHz radio without issues for about a month now.

16 Messages

 • 

214 Points

Excellent point. Back when this started, I was current. I'll upgrade to the most recent code and keep my fingers crossed. Thanks for the comment!

16 Messages

 • 

214 Points

9.6 is looking solid. It looks to be a problem with the 9.4 that I was hanging onto (can't remember why support didn't want me to upgrade at the time -- I think there was an issue with 5.1 they were fixing).

Thanks for the lead!

16 Messages

 • 

214 Points

Alas - it was good for only a few days as well. While it does seem to be a bit better, we're still seeing disconnects. This is very odd as I'm not seeing the same problem at another site/company. Support sent some recommendations surrounding changing the mgmt-tx-rate settings but that didn't resolve the issue. It feels like there's something simple that's being missed here.

683 Messages

 • 

11K Points

You've got one of our best techs looking at it, so it will definitely be interesting to find out the root cause. Stay tuned.

129 Messages

 • 

1.6K Points

"Tuning in..." any fixes yet?

Brand User

2.6K Messages

 • 

44.8K Points

7 years ago

Affected customers need to contact your vendor (Apple) to get latest radio drivers and supplicant to resolve this Apple problem.

The decision to roam is solely up to the client radio drivers and supplicant.

16 Messages

 • 

214 Points

Thanks for the thought, Michael, but the current radio drivers and patches are installed on these Apple systems (as of August 28, 2013).

Additionally, it only happens at this site. The problem does not occur at 2nd site (even though the Ruckus installation and ZD configurations are essentially the same).

129 Messages

 • 

1.6K Points

Michael: Is your response at all related to Keith Redfield's response? Thanks.

129 Messages

 • 

1.6K Points

IT Scott: Is your second site still problem free? Have you tried using one of your site#1 "problem" Mac devices at your second site?

Thanks, RiX

16 Messages

 • 

214 Points

Second site is still doing good (90% Mac there). My personal system is a Mac that is used at both sites. The problem still exists for me at the one site only (although it's much better with the SmartRoam=1 and with the DoS prevention off).

129 Messages

 • 

1.6K Points

Please let us know if you are ever able to determine the magic solution at site #2 !!!!

129 Messages

 • 

1.6K Points

7 years ago

Jeremy,

Did you ever fix your problem?

I have similar problems and need help.

Thanks, RB

99 Messages

 • 

2K Points

7 years ago

If you are using 9.6 and later try using the SmartRoam feature.

Here are the commands:
ruckus# config
ruckus(config)# wlan test
The WLAN service 'test' has been loaded. To save the WLAN service, type 'end' or 'exit'.
ruckus(config-wlan)# smart-roam
The command was executed successfully. To save the changes, type 'end' or 'exit'.
ruckus(config-wlan)# smart-roam 3
The command was executed successfully. To save the changes, type 'end' or 'exit'.
ruckus(config-wlan)# end
The WLAN service 'test' has been updated and saved.
Your changes have been saved.
ruckus(config)# end
Your changes have been saved.
ruckus#

The value after the smartroam is the roaming factor and it sets the low SNR/RSSI the AP receives form a client before it forces a client to disconnects.

Here are the different roaming factor and the associated low SNR/RSSI level:
Factor LoRSSI
1 5
2 10
3 15
4 17
5 20
6 23
7 27
8 32
9 40
10 60

The better the coverage the more aggressive you can be on forcing a client off an AP that receives a low client signal. Depending on the deployment different roam factor should be used. Also please note this is not officially support until the 9.7 release but code is in place. I would suggest starting from the low side and monitor/test carefully at each level before increasing the roam factor.

129 Messages

 • 

1.6K Points

Thanks

16 Messages

 • 

214 Points

This did not help with my situation. I'm still seeing client systems try to roam frequently when they shouldn't be. This is resulting in a greater than 2% packet loss while on the wireless network.

I continue to work with support but there's only so many times I can send in the log files for analysis. :(

129 Messages

 • 

1.6K Points

We are using primarily AP model ZF7982-US. I know Ruckus' design calls for the ZD to manage/control the ZF but the ZF units are also built for stand-alone. Is any "heavy" Mac (OSX / iOS) site that is not having "roaming / disconnect" problems as expressed in this post string using other AP models? If so, please list: AP model, ZD model, ZF soft version, (Mac, iPad, or iPhone model) OSX release, or iOS version.

Thanks, RiX

16 Messages

 • 

214 Points

I have one site with 70+ Mac users (90+ percent Mac) with ZD1100 and five 7363's that is working great! Another site with the same setup with 2AP's that's not. It's quite puzzling.

99 Messages

 • 

2K Points

Just to clarify, Enabling SmartRoam on the ZD, does not actually make the client's roaming function any smarter, it only limits the number of APs that will respond to a client's requests.
In theory the fewer the response, most likely from APs that are closer, the better the odds are of it making the correct decision as to which AP to roam to.

The only other thing you can do is to increase the Basic service rate to something higher. 1/6 Mbps on 2.4 GHz and 6 Mbps on 5 GHz can go farther than what is necessary good for data traffic. By increasing the BSS min rate you will effectively decrease the cell size, beacon at 24 Mbps for example will a shorter distance than that going at 6 Mbps, so for any given point in the network that has a BSS min rate of 24 Mbps there are fewer "AP" the client can hear, and of those that a client can hear it can definitely support a higher data rate for non-management traffic. The caution in doing this is that you may create coverage hole in your network. If you do this I would recommend starting from lower rate, 9 Mbps then 12 and so on until you get an acceptable "roaming" by the client and keep it there, then test for coverage holes.

683 Messages

 • 

11K Points

7 years ago

@All - is everyone seeing this issue running standalone APs? Reading the thread it's not clear who has ZD deployed or not.

BTW - we are not seeing this widespread (based on cases being opened, etc), so it's likely to be some corner/boundary condition that's being encountered.

16 Messages

 • 

214 Points

ZD1100 managed 7363's here.

7 Messages

 • 

170 Points

ZD3000 with 7363s and 7762s

1 Message

 • 

60 Points

Same issue here. ZD1100 2x7363, 7x7762

202 Messages

 • 

3K Points

In one building / situation, things seemed to get better when we took APs off of the (ZD3000) controller. That building had 7982 APs. The controller is currently running 9.6.1.0 build 18.

3 Messages

 • 

270 Points

7 years ago

my system has the zd 1100 deployed with several zf7363 AP's and we saw this problem until I updated to 9.5.2.0.15 firmware. I can't say the problem is "fixed" as much as I can say I haven't had any complaints. I don't own any apple devices to test with personally, but I've had one unsubstantiated report of a dropped connection, which I can live with.

2 Messages

 • 

130 Points

7 years ago

This is a bit long and details a special case - sorry.

We had a disconnect (not a roaming) problem with ipod touch back in 2011/2012.
We bought 20 ipod touch 4g 8GB, to pilot test a guided tour for schools with a custom, non app store app, done by a 3rd party, who also set up the ipods.
The ipods were consistently disconnecting and not automatically reconnecting.
ZD1100 with 19 APs (7962 and 7363 at the time)
Don't know the firmware version but it was current at the time (march 2012); 9.3 something.
ios was 5.1 - we couldn't update it for "fear of breaking the app".

WLAN (for most systematic testing) was static channel 20Mhz, no encryption, no 5Ghz radio, L2/MAC access control, 7363 AP, ZD1100 as above.

Spent almost a week doing systematic packet capture and found:

- ipods disconnected consistently but not invariably after 30 minutes and could only be reconnected with manual intervention.

- disconnection could sometimes be mitigated by allowing a disconnect/reconnect
sequence at startup
(if not unlocked the ipods disconnect automatically after 30 seconds, then reconnect after unlocking).

- amount of udp/tcp network activity had no effect on disconnection after 30 minutes - no "keepalive"/inactivity effect.
(we used a modfied app version which sent a tcp packet every 2 minutes and arp,
dns lookup and multicast activity was also observed)

- the wlan had no internet access, but opening the wlan and allowing ipods to "phone home" had no effect on disconnection.

- testing was mostly with the ipods in one location connected to a single 7363AP where no roaming occurred. Moving them around and getting them to roam within the 30 minute window before disconnection had no effect. They behaved "normally"
until disconnection.

- it was always the ipod that initiated the disconnection - never the AP.

- the behaviour of the ipods was the same in other non-ruckus wlans.

- 2 of the ipods did not exhibit the behaviour described and stayed connected
in all tested wlan environments.

- no other device (apple or otherwise) exhibited this disconnect behaviour.

Found a possible explanation why the interval before disconnection is 30 minutes
and was considering jail-breaking an iPod as a last resort.

http://www.ifans.com/forums/threads/i...

Contribution by "wvcachi" Jun 8, 2010
<>
If your touch is jailbroken, try this:
Use SSH or iFile to browse your touch's file system,
and go to var/preferences/SystemConfiguration and edit
the com.apple.wifi.plist file. Find the part that reads:

DisassociationInterval
1800

And change that 1800 to something much higher.
The number is how many seconds it will stay connected to wifi without its
being active (1800 is 30 minutes). I switched mine to 604800 - one week.

It could POSSIBLY be that that setting is what's causing your issue. Good luck!
<< Unquote >>

(The "without its being active" bit does not seem to be the case).

In our special case the ipods were the problem, not the network and before we sent 18 back to Apple, we finally found that the network state of the ipod at the
time the custom app was installed is key.
If it had no internet connection when the app was installed then the disconnect happened.
If it had an internet connection when the app was installed then it stayed connected.
So must/may be something to do with GUID checking of app/ipod/developer...
After reinstalling the ipods now work "as advertised"

Because the assumption was (always is?) "it must be the network", I had to spend a lot of time proving that it wasn't.

368 Messages

 • 

5.6K Points

You're awsome dude

21 Messages

 • 

470 Points

7 years ago

We are seeing similar issues. We called in one of our local Ruckus vendor and them take a look. Most of the issues he pointed out were radios mounted vertically.

I took him to some problem areas where the client keeps flapping from AP to AP, connecting to APs that are further away, etc. His gear showed that the signals were quite sufficient in all locations, noise was low, etc

The only theory he came up with was that the Apple units in question are most interested in 5ghz. His theory is that the Apple's are so interested in 5ghz that they connect to the 5ghz channel before the 2.4ghz even though the 2.4ghz would be better. Someone in the building sneezes and the hardware switches to 2.4ghz. The apple prefers 5ghz so after a while it flips backs. etc.

One item that lends itself to this theory being correct is last year we had a lot less disconnect issues. The primary thing that has changed? We have introduced a lot of new hardware which is 5ghz.

I am seeing clients "roaming" to the same AP by switching g/n to a/n.

Any thoughts?
Bob

129 Messages

 • 

1.6K Points

Bob:

Any "roaming" to the same AP resolution? We have begun to have the same problem with Apple iOS devices.

21 Messages

 • 

470 Points

Not as of yet. Although I have moved to the higher channels, only 149 and above, as they have a higher transmit power than the lower channels.

I am reading more and more that wireless networks are being adjusted as the future is 5GHZ. Networks designed for 2.4 ghz aren't dense enough.

Currently I am moving a number of APs in an attempt to get higher 5 ghz to the troubled clients.

Hope that helps,
Bob

129 Messages

 • 

1.6K Points

Ruckus: Does anyone at corporate care about these Mac issues? How about searching your corporate knowledgebase and/or oral history and provide some better answers. Good grief,buy a couple of iPads or Macbooks or _____ and run a few tests for yourselves.

16 Messages

 • 

214 Points

7 years ago

We tried adjusting the 5Ghz to a different SSID originally but that didn't seem to resolve the issue. I'll turn off the 5Ghz entirely and see if that resolves the disconnects. It still doesn't explain why the MacBooks don't rejoin the network after disconnecting... it's very odd - they just sit there disconnected even with the SSID available. Perhaps with no 5Ghz, the clients will behave in a more expected manner.

129 Messages

 • 

1.6K Points

7 years ago

We are still having similar roaming problems. For us, the "rejoin" only takes place after we "forget" the network and then reselect. We have had these types of "rejoining" issues using iPhone 5x and IPad mini all using current updates. We are also experimenting with 5Ghz.

Does anyone really know they solved their Apple roaming problems? If so, at least let us know there is hope and maybe your Ruckus support case number so we can advise our assigned technician of a possible solution(s).

21 Messages

 • 

470 Points

7 years ago

So, I can shed a little bit of light on ipad/ipod stuff. The Idevices, as soon as it connects to a wireless connection, try to hit their "success" page. This way, if the device is behind a "captive portal", the user will immediately be prompted for credentials. The success pages are located (on IOS7 at least) at captive.apple.com, ibook.info, airport.us, itools.info, thinkdifferent.us and appleiphonecell.com.

Here is where it gets interesting: If the user chooses to NOT enter the credentials in the captive portal, the device drops the wireless and, depending on the ios version (even small differences. for example 6.1.2 vs 6.1.3) disables the "autojoin" on the "network".

We have firewall rules in place so that no matter who the user is, always allow access to those domains at all times, day or night.

Hope that helps,
Bob