Any ideas? Has anyone seen anything like this before?
- 7 Posts
- 0 Reply Likes
- confused
Posted 6 years ago
Bittu, Employee
- 43 Posts
- 13 Reply Likes
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 Posts
- 8 Reply Likes
- 16 Posts
- 0 Reply Likes
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 Posts
- 2 Reply Likes
- 16 Posts
- 0 Reply Likes
9.6.1 is now out so that's my next order of business to try to get this fully resolved.
- 129 Posts
- 2 Reply Likes
- 16 Posts
- 0 Reply Likes
- 129 Posts
- 2 Reply Likes
Any good results?
- 3 Posts
- 8 Reply Likes
- 16 Posts
- 0 Reply Likes
- 16 Posts
- 0 Reply Likes
Thanks for the lead!
- 16 Posts
- 0 Reply Likes
- 860 Posts
- 52 Reply Likes
- 860 Posts
- 52 Reply Likes
Michael Brado, Official Rep
- 3079 Posts
- 444 Reply Likes
The decision to roam is solely up to the client radio drivers and supplicant.
- 16 Posts
- 0 Reply Likes
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 Posts
- 2 Reply Likes
- 129 Posts
- 2 Reply Likes
Thanks, RiX
- 16 Posts
- 0 Reply Likes
- 129 Posts
- 2 Reply Likes
- 16 Posts
- 0 Reply Likes
- 129 Posts
- 2 Reply Likes
Did you ever fix your problem?
I have similar problems and need help.
Thanks, RB
- 102 Posts
- 49 Reply Likes
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.
- 16 Posts
- 0 Reply Likes
I continue to work with support but there's only so many times I can send in the log files for analysis. :(
- 129 Posts
- 2 Reply Likes
Thanks, RiX
- 16 Posts
- 0 Reply Likes
- 102 Posts
- 49 Reply Likes
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.
- 16 Posts
- 0 Reply Likes
I'm in the process of dropping the SmartRoam down to 1 upon the advice of TechSupport and we'll test further.
- 129 Posts
- 2 Reply Likes
Did the "1" setting solve the disconnects for you?
ThX
- 16 Posts
- 0 Reply Likes
I also just turned off the DoS protection (under WIPS). It's possible that was preventing clients from reconnecting.
- 860 Posts
- 52 Reply Likes
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.
Bill Burns, AlphaDog
- 203 Posts
- 42 Reply Likes
- 3 Posts
- 8 Reply Likes
- 2 Posts
- 3 Reply Likes
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.
- 21 Posts
- 2 Reply Likes
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 Posts
- 2 Reply Likes
Any "roaming" to the same AP resolution? We have begun to have the same problem with Apple iOS devices.
- 21 Posts
- 2 Reply Likes
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 Posts
- 2 Reply Likes
- 16 Posts
- 0 Reply Likes
- 129 Posts
- 2 Reply Likes
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 Posts
- 2 Reply Likes
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
- 129 Posts
- 2 Reply Likes
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
- 7 Posts
- 0 Reply Likes
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.
- 129 Posts
- 2 Reply Likes
- 129 Posts
- 2 Reply Likes
Still good at your site? Let us know if you upgrade to most current general release firmware and results.
Bill Burns, AlphaDog
- 203 Posts
- 42 Reply Likes
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.
- 129 Posts
- 2 Reply Likes
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?
- 16 Posts
- 0 Reply Likes
Bill Burns, AlphaDog
- 203 Posts
- 42 Reply Likes
..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.
- 129 Posts
- 2 Reply Likes
Bill: Any more help from ruck tech support?
Bill Burns, AlphaDog
- 203 Posts
- 42 Reply Likes
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
- 203 Posts
- 42 Reply Likes
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.
- 860 Posts
- 52 Reply Likes
Bill Burns, AlphaDog
- 203 Posts
- 42 Reply Likes
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.
Bill Burns, AlphaDog
- 203 Posts
- 42 Reply Likes
https://github.com/bot779/ruckus-zdro...
- 3 Posts
- 0 Reply Likes
Bill Burns, AlphaDog
- 203 Posts
- 42 Reply Likes
'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.
- 129 Posts
- 2 Reply Likes
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
- 203 Posts
- 42 Reply Likes
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.
- 129 Posts
- 2 Reply Likes
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.
This conversation is no longer open for comments or replies.
Related Categories
-
ZoneDirector
- 2550 Conversations
- 732 Followers
-
Ruckus Indoor APs
- 1685 Conversations
- 693 Followers
-
Ruckus Outdoor APs
- 538 Conversations
- 370 Followers
-
General Wireless Questions
- 513 Conversations
- 347 Followers