WiFi Keeps Dropping Connections (R750 WAPs)

[SomeGuy543]

So I'm pretty new to this all, but to give some background, we've been using Ruckus Wifi access points for our local office network. As a stopgap until we received our Cisco networking equipment, we just used a regular home router, and the setup worked fairly well.

When we migrated to the Cisco network and configured the wireless system to work with it recently, I started noticing some problems. This also coincides with a period of rapid significant growth in users at the office, but I'm having trouble telling if it's due to that or maybe something on our Cisco network that's dropping the connections. At first we only had two APs for our office (which was fine on the old network for many months) and I noticed recently by looking at the data that a few of the connections were listed as "poor", so I added two more APs in to the mix. Now I don't see as many poor connections but I still notice pretty much every device seems to lose its connection to the Wifi network for a little at some point (after which it may reconnect if set to automatically reconnect, but this presents problems of course, especially with video calls). The actual signal strength of the network is good though, pretty much always full bars appearing on each device, and the connection itself, once it's on, is good. It just seems to randomly drop it fairly often.

I've tried taking a look at Logs under Diagnostics on our Unleashed dashboard, but they don't seem to indicate much. I also then went to the Client Troubleshooting section and tried to do a test with the MAC address of a certain computer's Wifi NIC but again it wasn't very helpful in terms of elucidating what's going on with the dropped connections. When the connection actually happens successfully, everything seems to check out on there, otherwise there isn't info on it. When I try to download the log, I get a .tac file that I can't do much with. Any advice on better troubleshooting with these logs?

Here's some information:

- mesh network is enabled

- both 5 GHz and 2.4 Ghz networks are enabled, but they are combined and set to auto

- radio is mostly 802.11ax but some are ac or n, and most have excellent or moderate signal strength

- *something to note is that all of the WAPs have a warning saying "Not enough electricity power is provided to this AP, its capabilities are degraded". But this has always been the case even from the start when we didn't have this problem with dropping connections. The Cisco switches that they are connected to are PoE and in one case we even added a separate PoE injector, but the warning is still there. Could this be part of the problem?

- we have over 35 users here but four APs in a medium sized office should handle that, I believe

- DHCP and all of that is not done on the Ruckus network but handled by the Cisco equipment it is connected to (switches, firewall, etc.)

- we do plan on eventually getting actual Cisco wireless equipment, but until then we want to get this stabilized

- I am considering doing a firmware update later today maybe

From the info I've given here (I can provide more if necessary), would you say I need to be looking at the Ruckus network itself or rather the Cisco network and security equipment behind it rather? Any tips to optimize our Ruckus wifi experience on the dashboard?

Thank you, and any advice is much appreciated.

[SomeGuy543]

Hi Vineet,

Sorry for bringing back this topic but it seems we are not totally good yet, if you could perhaps please shed some more light. There is significantly less dropping but it does still happen from time to time, seemingly more on certain hosts than others. Here is some system debug info from around the time of the disconnect, if this is useful (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?

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

[hakunamatomato]

did you find the solution to this rawkus?