Apple Device Roaming

  • 4
  • Question
  • Updated 3 years ago
  • Doesn't Need an Answer
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?
Photo of Jeremy West

Jeremy West

  • 7 Posts
  • 0 Reply Likes
  • confused

Posted 4 years ago

  • 4
Photo of Bittu

Bittu, Employee

  • 43 Posts
  • 13 Reply Likes
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.
Photo of Greg Gilbert

Greg Gilbert

  • 3 Posts
  • 8 Reply Likes
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.
Photo of Bittu

Bittu, Employee

  • 43 Posts
  • 13 Reply Likes
Valuable input Greg.. :-)
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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?
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
IT Scott: Any resolutions that "fixed" your OSX and iOS disconnect wifi problems?
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Thanks. We are running 9.6.1.0 build 15 "...no joy in Mudville..."
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
Nor here, RiX. The smart-roam option below didn't seem to help either.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Anyone with roaming issues try: 9.7.0.0.220 ?

Any good results?
Photo of Greg Gilbert

Greg Gilbert

  • 3 Posts
  • 8 Reply Likes
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.
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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!
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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.
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 50 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
"Tuning in..." any fixes yet?
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 50 Reply Likes
Looks like the original poster went to static channel assignment and the problem (mostly) resolved. @Jeremy - was the problem resolved?
Photo of Michael Brado

Michael Brado, Official Rep

  • 1979 Posts
  • 275 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
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
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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).
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Please let us know if you are ever able to determine the magic solution at site #2 !!!!
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
Unfortunately, it looks like it's started happening at my second site as well (with current versions). We're seeing clients (mostly Mac) start to excessively roam. That's not promising. :(
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Is your second site still having problems?
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Jeremy,

Did you ever fix your problem?

I have similar problems and need help.

Thanks, RB
Photo of Sid Sok

Sid Sok, Official Rep

  • 102 Posts
  • 48 Reply Likes
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.
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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.
Photo of Sid Sok

Sid Sok, Official Rep

  • 102 Posts
  • 48 Reply Likes
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.
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
Very interesting - we did this a few weeks ago and our 'edges' definitely came in a bit but the disconnects persist.
I'm in the process of dropping the SmartRoam down to 1 upon the advice of TechSupport and we'll test further.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
IT Scott:

Did the "1" setting solve the disconnects for you?

ThX
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
It helped but the problem still exists.
I also just turned off the DoS protection (under WIPS). It's possible that was preventing clients from reconnecting.
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
@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.
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
ZD1100 managed 7363's here.
Photo of Jeremy West

Jeremy West

  • 7 Posts
  • 0 Reply Likes
ZD3000 with 7363s and 7762s
Photo of Jake Stroud

Jake Stroud

  • 1 Post
  • 0 Reply Likes
Same issue here. ZD1100 2x7363, 7x7762
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of Greg Gilbert

Greg Gilbert

  • 3 Posts
  • 8 Reply Likes
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.
Photo of Chris Sherry

Chris Sherry

  • 2 Posts
  • 3 Reply Likes
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.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
You're awsome dude
Photo of Bob Williamson

Bob Williamson

  • 21 Posts
  • 2 Reply Likes
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
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Bob:

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

Bob Williamson

  • 21 Posts
  • 2 Reply Likes
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
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
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.
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
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).
Photo of Bob Williamson

Bob Williamson

  • 21 Posts
  • 2 Reply Likes
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
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
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
Photo of Jeremy West

Jeremy West

  • 7 Posts
  • 0 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
JW:

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

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
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?
Photo of ITScott

ITScott

  • 16 Posts
  • 0 Reply Likes
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 :)
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Smartroam at "1" did not help us.

Bill: Any more help from ruck tech support?
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
I'm working w/ a good tech-support rep now. Got all my tickets transferred to this one guy. The roaming rate (at least for the macbook air machines that I've been watching) has gone down to around 10 times a day instead of 100+ times a day. I'm not sure what/which change to attribute the improvement to.
I'm still not sure about iOS/android devices.
When looking at logs, It's hard to tell the difference between a device w/ an excessive roaming problem and a user that moves around all day.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 50 Reply Likes
Nice! Thanks for sharing!
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 50 Reply Likes
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
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
The zdroamers script is now updated to display the operating systems running on clients that roam frequently.
https://github.com/bot779/ruckus-zdro...
Photo of Darren Child

Darren Child

  • 3 Posts
  • 0 Reply Likes
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?
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Any resolution for you?
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
Bill:

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

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of ThX

ThX

  • 128 Posts
  • 2 Reply Likes
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.

This conversation is no longer open for comments or replies.