My iPhone keeps getting kicked off network - Help please

[douglas_liman]

This is the log for around the time it was kicked off (I have smart roam on at level 2 btw)

Jun 10 07:14:02 master - 1707 attic syslog: pid=2279, stamgr_cfg_adpt_build_ap_port_status():LAN label, the ap model is r510, the eth num is 0, the lan_append is  Port1, the label is 10/100/1000 PoE Port1  
Jun 10 07:14:02 master - 1707 attic syslog: upgrade_debug: pid=30926, get_ap_list(): see [/tmp/unleashed_upgrade/upgrade_ap_list_from_election.xml.ready], ap-list ready! 
Jun 10 07:14:02 master - 1707 attic syslog: upgrade_debug: pid=30926, get_ap_list(): ap-list loop 0. 
Jun 10 07:13:48 master - 1707 attic ZD-APMgr: IPC_thread rcv ping from TACMON 
Jun 10 07:13:29 master - 1707 attic syslog: pid=2279, _loadXmlStr():Unable to parse XML string (null) 
Jun 10 07:13:28 master - 1707 attic syslog: upgrade_debug: pid=30702, get_ap_list(): see [/tmp/unleashed_upgrade/upgrade_ap_list_from_election.xml.ready], ap-list ready! 
Jun 10 07:13:28 master - 1707 attic syslog: upgrade_debug: pid=30702, get_ap_list(): ap-list loop 0. 
Jun 10 07:13:23 master - 1707 attic stamgr: tac_del_arp:dev=br0 SIOCDARP failed, errno=6 
Jun 10 07:13:18 master - 1707 attic ZD-APMgr: IPC_thread rcv ping from TACMON 
Jun 10 07:13:03 master - 1707 attic last message repeated 2 times
Jun 10 07:12:52 master - 1707 attic stainfo[3871]: sta_info_detection_qmdpi_receive(911): Failed to identify device..!!!! No browser information  
Jun 10 07:12:48 master - 1707 attic ZD-APMgr: IPC_thread rcv ping from TACMON 
Jun 10 07:12:34 master - 1707 attic Eved: wlan1 88:a4:79:5e:82:55 : Authentication Difficulty 
Jun 10 07:12:28 master - 1707 attic syslog: pid=2279, _loadXmlStr():Unable to parse XML string (null) 
Jun 10 07:12:28 master - 1707 attic syslog: upgrade_debug: pid=30284, get_ap_list(): see [/tmp/unleashed_upgrade/upgrade_ap_list_from_election.xml.ready], ap-list ready! 
Jun 10 07:12:28 master - 1707 attic syslog: upgrade_debug: pid=30284, get_ap_list(): ap-list loop 0. 
Jun 10 07:12:26 master - 1707 attic syslog: pid=2280, AuthAdmin():password recovery already enabled, do not need prompt promotion 
Jun 10 07:12:26 master - 1707 attic syslog: pid=2280, AuthAdmin():admin login succeed, is_local_auth is 1 
Jun 10 07:12:26 master - 1707 attic syslog: pid=2280, LogoutAdmin():cred lookup fail 
Jun 10 07:12:21 master - 1707 attic kernel: [369641.595741] FWLOG: [110310706] RATE: ChainMask 3, peer_mac 82:55, phymode 5, ni_flags 0x00201006, vht_mcs_set 0x0000, ht_mcs_set 0xffff, legacy_rate_set 0x6933532
Jun 10 07:12:21 master - 1707 attic kernel: [369641.483149] net80211_tac_cfg_sta_set_param(): set station 88:a4:79:5e:82:55 vlan_id = 1
Jun 10 07:12:18 master - 1707 attic last message repeated 2 times

[david_black_594]

For starters I would completely disable smartroam.  The feature can be useful in certain situations, but most of the time it creates more problems than it solves.  The reason is that normal wifi roaming is a graceful make-before-break process.  The client is fully aware and in charge every step of the way.  Smartroam is the opposite - the AP boots the unsuspecting client off the network by sending a deauth frame.  The client sees this as an abrupt and unexpected disconnect, and then scrambles to find a new radio to associate with.  Unless you have an extreme sticky client issue, it's best to not use smartroam.

To disable, execute CLI command "no smart-roam" from the WLAN context. 

I assume the disconnects are not mere inactivity timeouts.  Are you being disconnected while in the middle of doing something?  This is just a guess due to lack of data, but you might try whacking transmit power.  Excessive transmit power is the root cause of a lot of issues.  Whatever you do on 5GHz, drop at least -4 more on 2.4 (eg: 5GHz -3; 2.4GHz -7 or -8).  

Lastly, if you have an active Unleashed support plan, you can create and account and open a case with Ruckus TAC https://support.ruckuswireless.com. If you don't have support, go to the same site and click the "purchase support" tab at the top.

[jp]

Thanks, sounds like useful hints. Since I also received complaints from iPhone users I had a look at the settings on my R650s (Unleashed), their TX power is set to "auto". What does this actually do? I could not find details in the documentation.

[david_black_594]

Unless you've enable so-called "self-healing" (default state is off), Ruckus' auto mode = full power.  Assuming the AP locations and density are correct, auto mode (full power) is almost always too hot, especially in high density deployments.  This creates sticky clients in some cases, confuses clients in other cases due to too many targets, exacerbates co-channel interference, guts network capacity, and drives retries through the roof due to the mismatch in client and AP transmit powers.  It's hard and sometime risky to offer advice when the design details are not known, but in general the first step is to determine the weak spots.  If you have a predictive, you can use that to discover where RSSI is weakest.  If no predictive, study the floor plan and AP locations.  Considering AP locations, distance, and number of walls, try to "eyeball" where the weakest coverage might be.  Go to those locations and using an analyzer such and Metageek Inssider or Farproc's WiFi Analyzer, measure the 5GHz RSSI.  Decrease transmit power one step at a time until the RSSI tends to hover around -65.  Next, decrease 2.4 until RSSI is about the same (or a little worse) which should be -4 to -6 down from the 5GHz setting.   

You may want to try the self healing first since it's easier.  Simply go to services/radio control/self healing and check the box for "automatically adjust AP radio power..."  Make sure background scanning is enabled for both bands.  Let it cook for a couple of days and see if things improve.  If you're still having problems, you can adjust power manually.  And be sure to not select ChannelFly.  Ruckus loves the feature, but to those on the front line who install and manage hundreds of networks, ChannelFly is the kiss of death. 

[jp]

I did indeed enable ChannelFly, since it sounds smart - kudos to marketing 🙂 .
Thanks a bunch, I will give it a try with self-healing!

[david_black_594]

And switch to Background Scanning for both bands.  After a few days, you can drop the scan interval from the default of 20 seconds to 3600 or so.