Clients dropping off Wireless network

[SomeGuy543]

This is continued from another topic I created that stopped being responded to for some reason. We are using 4 R750 APs. WLAN is meshed, I have it on channels 1, 6, and 11 for 2.4GHz band, PoE+ is enabled. I also turned on various radio control features like self-healing, background scanning, load balancing. Most of the clients seem to be on 5 Ghz anyway. But yeah, we keep getting client computers dropping now and then throughout the course of the day. It's not nearly as bad as it was before I made some changes but it still happens fairly consistently. Here is some output from the debugging when one of them dropped off (the mac of the host that dropped off is 04:cf:4b:19:18:97):

Nov 14 21:35:28 Contoso stamgr: stamgr_web_auth_update_traffic_counters():Station 04:cf:4b:19:18:97, update raffic counters fail
Nov 14 21:35:28 Contoso stamgr: accounting_sta_stop_impl():Accounting for 04:cf:4b:19:18:97 is stopped.
Nov 14 21:35:28 Contoso stamgr: stamgr_STA_put():free sta: 0x01f9a878, sta_info: 0x01f8d3d8, MAC: 04:cf:4b:19:18:97
Nov 14 21:35:28 Contoso stamgr: stamgr_remove_associated_sta():STA:04:cf:4b:19:18:97, sta_info->flags=0x4184000, sta->del_rc=3, sta->ref_cnt=2, reason=3, del_rc_str station disconnects
Nov 14 21:35:28 Contoso stamgr: stamgr_handle_remote_sta_leave():Deleting 04:cf:4b:19:18:97 on VAP 34:20:e3:15:56:9c with reason 3, result 0, roaming 0
Nov 14 21:35:28 Contoso stamgr: stamgr_web_auth_update_traffic_counters():Station 04:cf:4b:19:18:97, update raffic counters fail
Nov 14 21:35:28 Contoso stamgr: accounting_sta_stop_impl():Accounting for 04:cf:4b:19:18:97 is stopped.
Nov 14 21:35:28 Contoso APMgr@Ruckus_A: lwapp_get_sta_stats IEEE80211_RUCKUS_GET_STA_STATS=126 ioctl failed
Nov 14 21:35:28 Contoso kernel: [2242247.549299] wlan: [0:I:ANY] ol_ath_vdev_install_key_send: 3230: macaddr 04:cf:4b:19:18:97
Nov 14 21:35:28 Contoso kernel: [2242247.549294] wlan: [0:I:ANY] ol_ath_vdev_install_key_send: 3229: Keyix=0 Keylen=16 Keyflags=0 Cipher=0
Nov 14 21:35:28 Contoso kernel: [2242247.549283] wlan: [0:I:ANY] ol_ath_vdev_install_key_send: 3226: Is_group_key_valid=0 grp_key_idx=0
Nov 14 21:35:28 Contoso stamgr: tac_remote_sta_remove():send del sta (04:cf:4b:19:18:97) to remote AP
Nov 14 21:35:28 Contoso stamgr: tac_send_remote_sta_delete():send del sta (04:cf:4b:19:18:97) to remote AP with elmt_id=0xb00 radio=1, wlan id=0, reason=768
Nov 14 21:35:28 Contoso stamgr: stamgr_remove_associated_sta():STA:04:cf:4b:19:18:97, sta_info->flags=0x4094200, sta->del_rc=0, sta->ref_cnt=2, reason=3, del_rc_str station disconnects
Nov 14 21:35:28 Contoso stamgr: handle_deauth():VAP 34:20:e3:15:56:9c- STA 04:cf:4b:19:18:97 deauthenticated
Nov 14 21:35:28 Contoso stamgr: ieee802_1x_set_sta_authorized():VAP 34:20:e3:15:56:9c- unauthorizing port for STA 04:cf:4b:19:18:97
Nov 14 21:35:28 Contoso stamgr: handle_deauth():VAP 34:20:e3:15:56:9c- deauth frame from 04:cf:4b:19:18:97, reason_code=1
Nov 14 21:35:28 Contoso stamgr: ieee802_11_mgmt():VAP 34:20:e3:15:56:9c- received mgmt deauth frame from 04:cf:4b:19:18:97
Nov 14 21:35:28 Contoso stamgr: handle_frame():received mgmt frame type from 04:cf:4b:19:18:97 to AP (34:20:e3:15:56:9c)
Nov 14 21:35:28 Contoso stamgr: stamgr_get_sta_vlan():STA 04:cf:4b:19:18:97 uses vlan id 1, vap vlan id is 1, vlan pool vlanid is 0, sta_info vlan id is 0, vlan of device policy is 0, vlan of role is 0
Nov 14 21:35:28 Contoso stamgr: stamgr_get_sta_vlan():STA 04:cf:4b:19:18:97 uses vlan id 1, vap vlan id is 1, vlan pool vlanid is 0, sta_info vlan id is 0, vlan of device policy is 0, vlan of role is 0
Nov 14 21:35:28 Contoso stamgr: stamgr_handle_remote_ipc():Receive STA(04:cf:4b:19:18:97)'s vlan (1) dhcp-ip(10.1.26.104) lease-time(32400) xid(c1c1f5d4) dhcp-ack(16777216) from AP(34:20:e3:15:56:90)

I'm not sure why it's saying Vlan Id is 1, since the interface that the APs are on is a different VLAN. Or does that Cisco config not transfer over to the APs? Unless I'm completely misunderstanding this.

There is a lot more output but it doesn't fit on here due to the 20k character limit.

Thanks!

[Squozen]

What do the logs on the client say? I see this: received mgmt deauth frame from 04:cf:4b:19:18:97

So the client itself decided to disconnect. Its own logs should explain why.

[SomeGuy543]

Interesting. I generated an html report about WLAN stats, and it seems drivers are responsible much of the time. The order of most common reasons for disconnect is: network is disconnected by the driver, the driver disconnected while associating, the network is disconnected by the user, the network is disconnected due to a temporary-disconnect request, the driver disconnected. I updated my driver yesterday and have had a continuous session since.