Ruckus r730 Solo - Issue with 802.11ax

[namezys]

Sorry for the duplication, I mixed something.

Device: r730 for home use, solo

rkscli: get version
Ruckus R730 Multimedia Hotzone Wireless AP
Version: 114.0.0.0.6565
rkscli: get channel wifi1
wifi1 Channel: 60 (5300 Mhz) (Manual Channel Select)
rkscli: get power-mode
PoE Configured Mode      : Auto
Power Consumption Status : DC

I face with an issue: Wifi 6 is unstable.

Shortly configuration:

• channels: tried 116, 140, 132, 160
• channellisation: 80 Mhz
• clients: MacBook M1 (very unstable), iPhone 15, Samsung phone (very unstable), Windows laptop (no issue)

If I disable WiFi 6 (ax), everything works perfectly. Looks like a client drops the connection without good reason.

AP Logs:

Dec 26 23:17:53 RuckusAP daemon.info hostapd: wlan9: STA f4:d4:88:78:7f:ed IEEE 802.11: disassociated
Dec 26 23:17:53 RuckusAP daemon.info hostapd: wlan9: STA f4:d4:88:78:7f:ed IEEE 802.11: reason code = 0
Dec 26 23:17:53 RuckusAP daemon.info hostapd: wlan9: STA f4:d4:88:78:7f:ed IEEE 802.11: unknown reason code= 0
Dec 26 23:17:53 RuckusAP kern.info kernel: [787072.919770] wlan: [0:I:ANY] ol_ath_vdev_install_key_send: 2882: Is_group_key_valid=0 grp_key_idx=0
Dec 26 23:17:53 RuckusAP kern.info kernel: [787072.919782] wlan: [0:I:ANY] ol_ath_vdev_install_key_send: 2885: Keyix=0 Keylen=16 Keyflags=0 Cipher=0
Dec 26 23:17:53 RuckusAP kern.info kernel: [787072.919788] wlan: [0:I:ANY] ol_ath_vdev_install_key_send: 2886: macaddr f4:d4:88:78:7f:ed
Dec 26 23:17:53 RuckusAP daemon.info hostapd: wlan9: STA f4:d4:88:78:7f:ed IEEE 802.11: associated
RuckusAP daemon.info hostapd: wlan9: STA f4:d4:88:78:7f:ed WPA: mic_len:16 key_data_len:0, ie_len:0, gtk_len:0, igtk_kde_len:0, pad_len:0 ***
RuckusAP daemon.info hostapd: wlan9: STA f4:d4:88:78:7f:ed WPA: mic_len:16 key_data_len:56, ie_len:22, gtk_len:16, igtk_kde_len:0, pad_len:2 ***
RuckusAP daemon.info hostapd: wlan9: STA f4:d4:88:78:7f:ed WPA: pairwise key handshake completed (RSN)
RuckusAP kern.info kernel: [787073.020285] wlan: [567:I:ANY] ol_ath_vdev_install_key_send: 2882: Is_group_key_valid=0 grp_key_idx=0
RuckusAP kern.info kernel: [787073.020296] wlan: [567:I:ANY] ol_ath_vdev_install_key_send: 2885: Keyix=0 Keylen=16 Keyflags=0 Cipher=4
RuckusAP kern.info kernel: [787073.020302] wlan: [567:I:ANY] ol_ath_vdev_install_key_send: 2886: macaddr f4:d4:88:78:7f:ed

As I know, reason 0 is an invalid code for disassociation.

Luckily, I was able to find correlated messages in macOs kernel log (I hope I found correct messages)

kernel	563687.232276 wlan0.A[535584] [ik] handleDeauthEvent@22010:Triggering Deauth Suppression with Link Debounce Logic
kernel	I [ik] handleDeauthDisassocWithReAssoc@8666: Reason: Deauth,  status = 0 , IEEE reason = 15, flags = 0x0, authtype = 0, addr = 1c:3a:60:62:85:0c
kernel	563687.232345 wlan0.A[535585] [ik] handleDeauthDisassocWithReAssoc@8679:Current Deauth/Disassoc Time = 563687 Last Deauth/Disassoc Time = 563687 Min Time Diff = 20
kernel	I [ik] handleDeauthDisassocWithReAssoc@8697: Starting Link Debounce Timer with a timeout of = 2000 ms
kernel	563687.232374 wlan0.A[535586] [ik] triggerNeighborCacheReAssociation@9789:Neighbor Cache Channels 58
kernel	563687.232386 wlan0.A[535587] [ik] triggerNeighborCacheReAssociation@9832:Total reassoc channels =1. Reassoc chans used =1
kernel	563687.232460 wlan0.A[535588] wlan WLC_REASSOC =  (68)
wlan 0000: ff ff ff ff ff ff 00 00 01 00 00 00 3a e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ............:...................
wlan 0032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................................
wlan 0064: 00 00 00 00  | ....
kernel	I [ik] handleRoamScanStartEvent@21363: roamStartEv.status: 0 wle->status 0 roamStartEv.reason: -528348158 wle->reason: 2 Rssi -47
kernel	com.apple.p2p: reportDataPathEvents[6317]: Wifi Infra scan request. 2.4G: 13  5G: 25
kernel	LQM-WIFI-CT: rssi=-47(0 0) snr=0 bcn=0(0) txFrames=0 txRetry=0 txRate=0 rxFrames=0 rxRetry=0 rxRate=0 rxToss=0
kernel	com.apple.p2p: reportDataPathEvents[6367] : Roam Scan Started by FW

Looks like the reason is "Triggering Deauth Suppression with Link Debounce Logic". Unfortunately, my network knowledge is limited and I can't assume what does it means.

Finally, mac starts to look for roaming and decides to connect to the same AP in a short time. However, it results in 100 - 3000 ms without connection. It's unacceptable.

Can somebody assume where I should dig?

[syamantakomer]

Hi @namezys,

Looking at the macOs kernal log, reason for deauth is reason code = 15 (4-Way Handshake timeout).

kernel	I [ik] handleDeauthDisassocWithReAssoc@8666: Reason: Deauth,  status = 0 , IEEE reason = 15, flags = 0x0, authtype = 0, addr = 1c:3a:60:62:85:0c

Now below entry in kernel log seems related to indication of frequent deauths but not the actual cause of deauth.

Deauth Suppression with Link Debounce Logic

Could you try flashing the AP with Unleashed software or manage it using any of the RUCKUS Controllers and see if problem persist.

If you are able to reproduce the problem all the time, I suggest you to raise a case with RUCKUS Support for further troubleshooting.

[namezys]

Hi @syamantakomer 

Unfortunately, it's r730 and I don't have unleashed firmware. Maybe you have?
Thank you for confirmation, I thought that the reason is "(4-Way Handshake timeout)".
Maybe you can suggest what I should care about in the logs?

I can reproduse error very offten. Sometimes it looks like it disappeared and everything works but if it returns, it will be repeated with high probability. 
Unfortunately, it's a home, so I don't have access to enterprise support. As I understand the only thing that I can do it's post here. However, I'm very curious and want to investigate this case.

Also, I tried with a virtual controller that was run in Proxmox. In the short test, there were no errors. I can run a longer test. I just to inform, you that I have two r730, one is assigned to this controller and disconnected right now so I can run it with the controller and disconnect solo.

PS: it's a good opportunity to learn new for me

[syamantakomer]

Sorry I missed that R730 is not supported on Unleashed. However, you can connect both your APs to your controller and shouldn't face any issues.

Without proper logs and captures from the problem time, it will be hard to check such connectivity issues. So far we have not received any major complaints related to this.

[namezys]

@syamantakomer 

I can capture any logs. However, there are to many logs on macOS and too few logs on r730.

I can use controller in trial mode only for testing as 16Gb of RAM to much for a flat. As I remember, there was no a problem with controller.

Can you help me to get more detail log? On AP there is no anythings for minutes.