nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Apple Device Roaming

unknown

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?

Find more posts tagged with

Accepted answers

All comments

santosh_bittu

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.

unknown

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.

santosh_bittu

Valuable input Greg.. 🙂

unknown

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?

unknown

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.

unknown

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!

unknown

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!

unknown

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.

michael_brado

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.

unknown

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).

unknown

Jeremy,

Did you ever fix your problem?

I have similar problems and need help.

Thanks, RB

unknown

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

unknown

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

unknown

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.

unknown

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

sid_sok

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.

unknown

Thanks

unknown

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. 😞

unknown

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

keith_redfield

@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.

unknown

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.

unknown

ZD1100 managed 7363's here.

unknown

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.

unknown

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

unknown

You're awsome dude

unknown

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

unknown

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.

unknown

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).

unknown

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

unknown

Consume with a grain of SALT:

Apple Blocks Lawrence Lessig's Comment On iOS 7 Wi-Fi Glitch

http://rss.slashdot.org/~r/Slashdot/s...

destinyland writes "A glitch in iOS7 has cost "a significant number" of Apple users their Wi-Fi access, according to ZDNet. But they also report that Apple is now censoring posts in their "Apple Support Communities" forums where users suggest possible responses to their loss of WiFi capabilities (including exercising their product warranty en masse). "We understand the desire to share experiences in your topic, 'Re: wifi greyed out after update to ios7,'" read one warning sent to Lawrence Lessig, "but because these posts are not allowed on our forums, we have removed it." Lessig — who co-founded Creative Commons (and was a board member of the Free Software Foundation) has been documenting the ongoing "comments slaughter" on his Twitter feed, drawing attention to what he says is the Borg-like behavior of Apple as a corporation. Lessig "is now part of an angry mob in Apple's forums who upgraded to iOS 7 and lost Wi-Fi connectivity," ZDNet notes, adding that as of this morning their reporter has been unable to obtain an official response from Apple."

Read more of this story at Slashdot.

shared via http://feedly.com

unknown

As some background to my original problem, I am using a ZD3000 with a combination of 7363 and 7762 APs (74 total).

This does appear to be resolved now for us. We did a number of things in trying to resolve it and I can't say for sure that it was one thing or another. These are the steps I took:

1) enabled 802.11d support

2) turned off client load balancing

3) statically assigned 2.4GHz channels and turned off background scanning

4) Upgraded from 9.3.x to 9.4.3.0.16 (I know that is old now)

5) Adjusted transmit power on 2.4 radios to try to reduce interference (but there really wasn't much present to begin with)

Upon doing these things, the system stabilized and has remained stable for the last 4ish months. Hope this helps.

unknown

ZD3000 with 7363s and 7762s

unknown

I'm having excessive roaming issues with macbook air laptops.

I've got a pair of ZD3000s running the latest 9.6 code w/ about 60 APs.

In one building/complex I've got 20 zf7372 APs.

One client there has roamed over 250 times today and there's a noticible impact on connectivity every time the client roams.

(sometimes the client renews it's lease w/ the DHCP server, sometimes it doesn't bother but resumes talking on the network anyway)

This user has an AP directly outside of his office, but the macbook air continually associates to 2 other APs on different floors.

In the past I've had iOS users comment that they're continually prompted if they want to connect to the (only available) SSID.

I've also seen situations where a windows7 laptop jumps back and forth between 2.4Ghz and 5Ghz radios of the same AP. The windows machine will do this for some time before getting confused and staying associated to one radio but without connectivity.

So far Ive turned on:

smartroam 2 (used to be "5". did this to prevent "stuck client" issue)

802.1d

ofdm-only

bss-minrate

regionalization and available channels are set to "optimize for performance"

Channelization is 20 for 2.4Ghz and 40 for 5Ghz.

turned off:

background scanning

load balancing is enabled.

Still looking for a solution.

unknown

Bill Burns:

We are having similar roaming problems related to Macs.

Has Ruckus provided you any help?

Others:

Has any Mac / Ruckus customer ever have the roaming issue working regularly and successfully...maybe with an older version of ruckus firmware or older OSX/iOS?

unknown

Bob:

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

unknown

Worked OK for me for 2 hours. This is better than the original 10 minutes. Client was idle the last 30 minutes of the 2 hours. Idle and grace each are set for 120.

unknown

I have one site that is pretty solid. ZD1100 with AP7363s - all current versions (and current OSX). I wish I could clone that at my second site 🙂

unknown

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

unknown

Tech Support recommends capturing data from the client machine w/ wireshark. (along with WiFi headers)

..and simultaneously using another wireshark instance along w/ an AP as a remote capture interface.

The user with this problem was out for the day so I just spent *my* day in his office trying to replicate the problem with another macbook air but with no success.

So I have no useful data to send back to Tech Support on this problem.

Will keep on trying.

unknown

Smartroam at "1" did not help us.

Bill: Any more help from ruck tech support?

unknown

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.

unknown

Same issue here. ZD1100 2x7363, 7x7762

unknown

I wrote this script to help me search for odd things in my ruckus logs:

https://github.com/bot779/ruckus-zdro...

Using this, I can see that the apple-branded device on my network that roamed the most yesterday had a mac address of 8c:58:77:19:4c:c9 and it roamed 192 times that day.

(it can take a long time to run)

I hope that helps someone.

keith_redfield

Nice! Thanks for sharing!

unknown

Here's another script. (or set of scripts?)

https://github.com/bot779/ruckusconf

"ruckusconf" will automate an ssh login and download of configs from a controller, or get a supportfile from an AP, or from a group of APs.

"buildclientos" will build a database of wifi client mac addresses and the operating systems running on those clients.

I hope to update the zdroamers script (soon-ish?) so it can use this information to display operating systems of the clients that are roaming the most.

This won't tell me if it's "macbook air" machines that roam the most, but at least I'll be able to distinguish between ios devices and laptops.

keith_redfield

This is a great conversation that's separate from the main topic, so I created a new topic to continue the discussion. Please reference the new topic here: Ruckus Log Search Script

unknown

The zdroamers script is now updated to display the operating systems running on clients that roam frequently.

https://github.com/bot779/ruckus-zdro...

unknown

I am having this same problem with MACS. I have been working with ruckus tech support for some time now. They still have not been able to come up with a good solution. The problem started occurring when I upgrade from 9.5.2 to 9.6.2. I am having this problem across multiple sites with multiple zds. Has anyone come up with a good solution?

unknown

I don't *think* I'm having these problems anymore.

'though I lost track of what changes heppened at what time:

I'm guessing the fix (for me) was to set the bss-minrate to 12.

note:

ofdm-only is good too.

band-steering thresholds may play-in to apple roaming as well.

I have smartroam turned on. (to deal w/ the "stuck client" issue)

smartroam *may* contribute to the problem.

unknown

It seems like RuckusWireless does not understand they have or will loose new customers because of these ROAMING problems.

We bought Ruckus party because of then current customers recommendations. If we are asked for the foreseeable future, we will push others away from Ruckus if the potential customer has a BYOD environment that includes at a minimum, MAC OSX.

unknown

JW:

Still good at your site? Let us know if you upgrade to most current general release firmware and results.

unknown

Bill:

Would you mind giving a copy of your configuration and logs to RuckusWireless support so they can study and post some solutions ("Answers")?

keith_redfield

We need everyone seeing this to open a case if you haven't already. We have only a handful now (really) and we're not getting enough data to proceed rapidly to resolution. When you open the case, or comment on an existing one, cite this post and request that the case be escalated.

I'll try to have something cohesive posted later today for possible workarounds.

unknown

Can't dump the entire config here.

Let me know what you want to see other than the wlan config.

root@/etc/admin/ruckus# ./ruckusconf --enable --command "show wlan name CSHL" $CONTROLLER_IP

spawn ssh admin@

Please login: admin

Password:

What is the correct access password?

Welcome to the Ruckus Wireless ZoneDirector 3000 Command Line Interface

ruckus>

ruckus> ena

ruckus# show wlan name CSHL

WLAN Service:

ID:

1:

NAME = CSHL

Tx. Rate of Management Frame(2.4GHz) = 12.0Mbps

Beacon Interval = 100ms

SSID = CSHL

Description = Production CSHL

Type = Standard Usage

Authentication = open

Encryption = none

Web Authentication = Disabled

Authentication Server = Disabled

Called-Station-Id type = wlan-bssid

Tunnel Mode = Disabled

Background Scanning = Enabled

Max. Clients = 200

Client Isolation = Local

Zero-IT Activation = Disabled

Priority = High

Load Balancing = Enabled

Rate Limiting Uplink = Disabled

Rate Limiting Downlink = Disabled

Auto-Proxy configuration:

Status = Disabled

Inactivity Timeout:

Status = Enabled

Timeout = 5 Minutes

VLAN-ID = 48

Dynamic VLAN = Disabled

Closed System = Disabled

OFDM-Only State = Enabled

Multicast Filter State = Disabled

802.11d State = Enabled

DHCP Option82 State = Disabled

Ignore unauthorized client statistic = Disabled

STA Info Extraction State = Enabled

BSS Minrate = 12.0 Mbps

Call Admission Control State = Disabled

PMK Cache Timeout= 720 minutes

PMK Cache for Reconnect= Enabled

NAS-ID Type= wlan-bssid

Roaming Acct-Interim-Update= Disabled

PAP Message Authenticator = Enabled

Send EAP-Failure = Disabled

L2/MAC = No ACLS

L3/L4/IP Address = No ACLS

L3/L4/IPv6 Address = No ACLS

Precedence = Default

Proxy ARP = Disabled

Device Policy = No ACLS

SmartRoam = Enabled Roam-factor = 4

ruckus# exit

Exit Ruckus CLI.

Connection to 143.48.126.1 closed.

unknown

Any resolution for you?

unknown

Where did you post the "workarounds?"

Much appreciated.

unknown

The only thing I have come up with is to setup a separate ssid with layer 2 MAC filtering.

unknown

DC:

Was that the Ruckus support proposed workaround?

keith_redfield

I'm closing the thread as this is proving unproductive.

This is not a common issue and we have yet enough diagnostics for conclusive root cause determination (@Bill's comes closest, and seems successfully resolved, but unfortunately too many variables changed simultaneously)

All of the available workarounds are posted in the thread. Please open a support case if you are seeing an issue with excessive/illogical roaming by either Apple or other devices. I have our escalation team standing by to assist.