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?
Any ideas? Has anyone seen anything like this before?
Posted 7 years ago
Bittu, Employee
Bittu, Employee
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?
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?
IT Scott: Any resolutions that "fixed" your OSX and iOS disconnect wifi problems?
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.
9.6.1 is now out so that's my next order of business to try to get this fully resolved.
Thanks. We are running 9.6.1.0 build 15 "...no joy in Mudville..."
Nor here, RiX. The smart-roam option below didn't seem to help either.
Anyone with roaming issues try: 9.7.0.0.220 ?
Any good results?
Any good results?
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.
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!
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!
Thanks for the lead!
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.
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.
"Tuning in..." any fixes yet?
Looks like the original poster went to static channel assignment and the problem (mostly) resolved. @Jeremy - was the problem resolved?
Michael Brado, Official Rep
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.
The decision to roam is solely up to the client radio drivers and supplicant.
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).
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).
Michael: Is your response at all related to Keith Redfield's response? Thanks.
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
Thanks, RiX
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).
Please let us know if you are ever able to determine the magic solution at site #2 !!!!
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. :(
Is your second site still having problems?
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.
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.
Thanks
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. :(
I continue to work with support but there's only so many times I can send in the log files for analysis. :(
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
Thanks, RiX
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.
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.
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.
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.
I'm in the process of dropping the SmartRoam down to 1 upon the advice of TechSupport and we'll test further.
IT Scott:
Did the "1" setting solve the disconnects for you?
ThX
Did the "1" setting solve the disconnects for you?
ThX
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.
I also just turned off the DoS protection (under WIPS). It's possible that was preventing clients from reconnecting.
@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.
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.
ZD1100 managed 7363's here.
ZD3000 with 7363s and 7762s
Same issue here. ZD1100 2x7363, 7x7762
Bill Burns, AlphaDog
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.
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.
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.
Primož Marinšek, AlphaDog
You're awsome dude
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
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
Bob:
Any "roaming" to the same AP resolution? We have begun to have the same problem with Apple iOS devices.
Any "roaming" to the same AP resolution? We have begun to have the same problem with Apple iOS devices.
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
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
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.
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.
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.
Bill Burns, AlphaDog
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?
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?
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 :)
Bill Burns, AlphaDog
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.
..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.
Smartroam at "1" did not help us.
Bill: Any more help from ruck tech support?
Bill: Any more help from ruck tech support?
Bill Burns, AlphaDog
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.
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.
Bill Burns, AlphaDog
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.
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.
Nice! Thanks for sharing!
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
Bill Burns, AlphaDog
Bill Burns, AlphaDog
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?
Any resolution for you?
Bill Burns, AlphaDog
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.
'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.
Bill:
Would you mind giving a copy of your configuration and logs to RuckusWireless support so they can study and post some solutions ("Answers")?
Would you mind giving a copy of your configuration and logs to RuckusWireless support so they can study and post some solutions ("Answers")?
Bill Burns, AlphaDog
Can't dump the entire config here.
Let me know what you want to see other than the wlan config.
[email protected]/etc/admin/ruckus# ./ruckusconf --enable --command "show wlan name CSHL" $CONTROLLER_IP
spawn ssh [email protected]
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.
Let me know what you want to see other than the wlan config.
[email protected]/etc/admin/ruckus# ./ruckusconf --enable --command "show wlan name CSHL" $CONTROLLER_IP
spawn ssh [email protected]
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.
