[NWA50BE] Wyze device compatibility issues in 802.11n mode

ExemplifyAdventure

I just purchased this about a week ago and so far I'm very happy. I appreciate that the built-in user interface is so efficient and capable without any fluff on top. Excellent work!

Unfortunately, I'm having a problem with some devices repeatedly dropping their wireless connection. After an indeterminate period of time, the device will disconnect from the wifi. Rebooting the AP will allow the device to reconnect, as will power cycling the device. The affected devices are:

• Wyze v3 camera. This will occasionally reconnect without intervention.
• Wyze Doorbell v2 (hardwired). This will never reconnect without intervention.
• Lenovo Win11 laptop, fully up to date including recent wifi drivers. This will show zero signal strength, even ten feet from the AP with an open line of sight. This will never reconnect without intervention.
• iPhone 16 Pro. This will occasionally reconnect without intervention.

Some logs for the Wyze cam v3 around the time of failure look like this:

(redacted)23:6c connected on Channel: 11, SSID: 56k_dialup, 2.4GHz, Signal: -52dBm, Interface: wlan-1-1

(redacted)23:6c blocked by key handshake fail on Channel: 11, SSID: 56k_dialup, 2.4GHz, Signal: -54dBm, Download/Upload: 113Bytes/135Bytes, reason 15, Interface: wlan-1-1

(redacted)23:6c deauthenticated by key handshake fail

(redacted)23:6c disconnected by STA reconnect on Channel: 11, SSID: 56k_dialup, 2.4GHz, Signal: -53dBm, Download/Upload: 0Bytes/0Bytes, reason 8, Interface: wlan-1-1

(redacted)23:6c blocked by key handshake fail on Channel: 11, SSID: 56k_dialup, 2.4GHz, Signal: -53dBm, Download/Upload: 0Bytes/135Bytes, reason 15, Interface: wlan-1-1

(redacted)23:6c deauthenticated by key handshake fail

(redacted)23:6c disconnected by STA timeout on Channel: 11, SSID: 56k_dialup, 2.4GHz, -54dBm, Download/Upload: 1.06MB/6.70MB, reason 34, Interface: wlan-1-1

I also sometimes get "auth timeout" errors from other devices, but it appears they either aren't actually losing their connection, or they're reconnecting before I notice. I've done a signal check at all points and signal strength is acceptable.

Things I've tried:

• Reverting to my old TP-Link wireless router in bridge mode. This immediately resolved the issue.
• Switching the NWA50BE to b/g mode instead of n mode. This appears to be my biggest help yet; all devices have been stable for the past 7 hours. The logs are empty aside from my web login. This suggests a compatibility issue between the Wyze devices and the AP.
• Repositioning the AP. The doorbell is located approximately 80 degrees to the side of the AP and down a flight of stairs. I rotated the AP so that it is facing the doorbell. This does not appear to have made any meaningful difference, as expected.
• Rebooting my entire network stack: OPNsense firewall, core switch, AP. This made no difference, as expected.
• Confirmed the AP is up to date on firmware (V7.30(4)).
• Confirmed the Wyze cam and laptops are up to date.

One other issue I've noticed is that my iPhone 16 Pro insists the SSID is hidden. It's not. I've removed and re-added the SSID to no avail. I'm willing to chalk this up to Apple being weird, but I wanted to include it in case it helps.

Can anyone offer any suggestions? As much as I like this AP, I would prefer not to leave it in b/g mode.

Zyxel_Judy

Hi @ExemplifyAdventure ,

From the event logs, here is the explanation and recommendation:

• Blocked by key handshake fail: A 4-way handshake failure occurs during the security authentication phase. While this can sometimes be caused by an incorrect password, your logs show the client was previously connected. In your case, because your signal strength is excellent (-52dBm to -54dBm), the failure is highly likely caused by wireless interference or high channel utilization/packet loss during the handshake process. Please refer to the article to re-configure:

What does the 'blocked by key handshake fail' log mean and how to resolve the issue? — Zyxel Community

• "Reason 8" (Disassociated because sending STA is leaving): This corresponds to IEEE 802.11 Reason Code 8, which indicates that the client device (STA) is voluntarily leaving the network. This is a client-initiated behavior (such as entering a power-saving sleep mode, disabling its own Wi-Fi, or attempting to roam) rather than an AP-side kick or failure.

If the issue still recurs after re-configuration, please share the Nebula organization & site and enable Zyxel support