[Release Note] Zyxel AX/AXE series Access Point - V7.10 Patch 3 firmware has been released

Zyxel_Melen

AX/AXE series Access Points Firmware Release Note 

July 2025

Overview

This document provides firmware release information on Zyxel Access Points platforms, introduce new Access Points, new features and enhancements, bug fix, known issues and workarounds information for Release V7.10 Patch 3 C0.

Supported Platforms

(Click Hyperlink to download the firmware directly)

WiFi 6E model(s):

Zyxel WAX640S-6E - V7.10(ACCM.3)C0

Zyxel WAX620D-6E - V7.10(ACCN.3)C0

Zyxel NWA220AX-6E - V7.10(ACCO.3)C0

WiFi 6 model(s):

Zyxel WAX655E - V7.10(ACDO.3)C0

Zyxel WAX650S - V7.10(ABRM.3)C0

Zyxel WAX630S - V7.10(ABZD.3)C0

Zyxel WAX610D - V7.10(ABTE.3)C0

Zyxel WAX510D - V7.10(ABTF.3)C0

Zyxel WAX300H - V7.10(ACHF.3)C0

Zyxel NWA210AX - V7.10(ABTD.3)C0

Zyxel NWA110AX - V7.10(ABTG.3)C0

Zyxel NWA90AX PRO - V7.10(ACGF.3)C0

Zyxel NWA50AX PRO - V7.10(ACGE.3)C0

Zyxel NWA50AX - V7.10(ABYW.3)C0

Zyxel NWA55AXE - V7.10(ABZL.3)C0

Zyxel NWA90AX - V7.10(ACCV.3)C0

New Features and Enhancements

1. Added support for the Administrative Access feature on supported models on Nebula Control Center. This feature allows access to device services (e.g., SSH, HTTPS) only from trusted IP addresses. Important: After upgrading to firmware version 7.10 Patch 3, if you have previously configured Switch Access Management on the Nebula Control Center, your managed access points will only be manageable from trusted IP addresses. 

2. A configurable syslog prefix is now available on Nebula Control Center for external syslog servers.

Bug Fix

C=Cloud mode, M=Managed, S=Standalone mode

Bug fix	C	M	S
1. [eITS: 250301420] [Symptom] STA should be assigned to a specific VLAN IP via 802.1x and RADIUS, but is incorrectly receiving an IP address from VLAN 1.	V	V	V
2. [eITS: 250400162] [Symptom] Wireless clients are incorrectly displayed as Ethernet clients in the topology and client list.	V	-	-
3. [eITS: 250500088] [Symptom] When the NWA55AXE operates in repeater mode and broadcasts a Guest SSID, any configuration changes made via Nebula cause the wireless bridge to become unstable.	V	-	-
4. [Vulnerability] CVE-2025-6265 Potential path traversal vulnerability.	V	V	V

Known Issue

C=Cloud mode, M=Managed, S=Standalone mode

Known Issue	C	M	S
1. [eITS: 250400010, 250601835] [Symptom] In a WDS roaming scenario, STA signal strength is incorrectly shown as 0 dBm. The Station Info list is not cleared after the SSID is disabled via scheduling. The number of connected clients shown in Station Info does not match the count displayed in the WLAN interface status summary.	-	-	V
2. [eITS: 250601637] [Symptom] When Fast Roaming is enabled, wireless clients that send multiple OMK IDs during authentication may fail to connect.	V	-	-
3. [eITS: 250401445] [Symptom] VLAN and Security fields in the clients list display incorrect values when 1x MAC authentication with VLAN assignment is used.	V	V	V
4. [SPRID: 241219350] [Symptom] The wireless monitoring data exhibits abnormal behavior.	V	-	-

Limitation of Settings

N/A

Pbee

[WAX650S] We've been getting reports of users with Apple Sillicon MacBook Pro's (M2/M3) having sudden wifi disconnects. When searching the logs there's pattern of "reason 8" disconnects invoked by the MacBook Pro followed by a "blocked by group rekey handshake fail" and/or "blocked by key handshake fail"
The time between disconnect and reconnect varies from seconds to several minutes, making the user believe the wifi is down which actually isn't the case as other wifi clients continue to function.

We do see "blocked by key handshake fail" log messages on other Apple devices like watches and HomePod's, but these are less frequent and often go unnoticed.

According to some posts on reddit and here on this forum, this is a known issue? Apparently there's a discrepancy in the WPA3 implementation by Apple and Zyxel? I'm hoping this will be fixed asap, because the workaround stepping back to WPA2 isn't really a great sollution.

Zyxel_Melen

Hi @Pbee

Could you help to collect the diagnostic file when this issue happens? We would like to check if the issue symptom as same as what we currently checking. 10 ~ 15 minutes after should be OK since the issue logs should still exists.

https://community.zyxel.com/en/discussion/22983/how-to-collect-the-ap-diaginfo-on-the-standalone-mode

Pbee

This is an log exerpt:

15-01-2026 23:41:45msg="Station: 94:ea:32:72:e1:b3 left on Channel: 36, SSID: XXXXXX-5GHz, 5GHz,Signal: -54dBm, Download/Upload: 23.86MB/3.99MB, reason 8, Interface: wlan-2-1"

15-01-2026 23:41:48msg="Station: 94:ea:32:72:e1:b3 connected on Channel: 36, SSID: XXXXXX-5GHz, 5GHz,Signal: -52dBm. Interface:wlan-2-1"

15-01-2026 23:41:48msg="Station: 94:ea:32:72:e1:b3 blocked by key handshake fail on Channel: 36,SSID: XXXXXX-5GHz, 5GHz, Signal: -54dBm, Download/Upload: 0Bytes/0Bytes,reason 2, Interface: wlan-2-1"

15-01-2026 23:41:48msg="Station: 94:ea:32:72:e1:b3 connected on Channel: 36, SSID: XXXXXX-5GHz, 5GHz, Signal: -52dBm. Interface:wlan-2-1"

I went over all other clients in the logs and found out that most Apple devices using WPA3 always go through this error before finally reconnecting. Active users notice this with suddenly freezing web activity or similar applications.
Apparently this is an Apple issue, exactly like this post:

https://community.zyxel.com/en/discussion/29375/blocked-by-key-handshake-fail-iphone-16-ios

Then I noticed another pattern: I saw a lot of reconnection attempts of HomePod's. The time pattern closely matches the "Idle Time-out" parameter as is set in the WPAx security profile. 360 seconds, apparently the default value? This kind of explains why HomePod's playing music (standalone mode) kind sometimes are silent for a second or 2. This happens when it's internal cache is just about to fetch new data when a reconnection is initiated, due to this Idle Time-out value.
So yesterday I changed that to 7200 seconds and that reduced the interruptions. The Group Key Timer is unchanged: 30000 seconds default. According to users they noticed significant less interruptions and indeed the 24 hour log is now also shorter than before. Some HomePod's now show a an hourly reconnect instead of every few minutes.

Coincidentally a while back I was researching issues with AirPlay (audio/video and audio-only) from wifi clients to wired AppleTV's. Most of this was fixed by adjusting the DTIM and beacon interval to Apple's expected values (DTIM=3 beacon=100ms), still every once in a while streaming got interrupted. Since our wifi network is surrounded by other wifi that is not under our control (modern cars in the parking lot next-door with chatty wifi in them), I assumed that we just suffered short interference from them. But after I searched for "key handshake fail" on the older logs it seems to fit the interruption pattern.

So for now I can reduce the symptoms, but the actual WPA3/SAE issue still remains. I assume this will be addressed with Apple?

OS versions client devices affected.
macOS 15.7.3, macOS 26.?, homepodOS 26, iOS 26.2, iPadOS 26.2

AP:
main network is 5GHz only (2.4GHz is fully separate with different SSID)
* no band steering
* no roaming
* U-APSD ON
* A-MPDU Aggregation ON
* A-MSDU Aggregation ON
* WPA3 personal (planning to move to WPA3 Enterprise)