Best Of

With the release of AP firmware 7.20, Zyxel has aligned its WiFi 7 access points with the WiFi Alliance’s updated security requirements for 802.11be operation. These changes affect which authentication and encryption protocols are permitted, particularly in the 6 GHz band, and introduce important adjustments for backward compatibility.

WiFi Alliance Security Requirements

For 802.11be radios, the following security methods are supported:

• Enhanced Open (no transition mode)
• WPA3-Personal
• WPA3-Enterprise
• WPA3-Personal with Transition Mode (excluded on 6 GHz)

For 6 GHz radios (including when set to 802.11ax mode):

• Enhanced Open
• WPA3-Personal
• WPA3-Enterprise
• ❌ No transition mode allowed

Prohibited methods on 11be radios:

• WEP
• Dynamic PSK (DPSK)
• WPA2-Personal / WPA2-Enterprise
• Any open/WPA2 modes not explicitly listed

This ensures that WiFi 7 deployments remain secure and free from vulnerabilities tied to outdated protocols.

What Happens With Unsupported Configurations

Although administrators can still select any method in the SSID profile GUI, the AP enforces compliance:

• Complete SSID disablement (e.g., WEP or DPSK on 6 GHz)
• Automatic adaptation to the closest supported method (e.g., WPA2 → WPA3)

This prevents insecure operation while keeping the network functional.

Evolution of the “Next Best” Security Method

Before Firmware 7.20

• 6 GHz radios automatically converted:
  • Open → Enhanced Open
  • WPA2-Personal → WPA3-Personal
  • WPA2-Enterprise → WPA3-Enterprise
• 2.4 GHz & 5 GHz radios unaffected (unless MLO enabled).

Firmware 7.20 Changes

• MLO is mandatory on all 11be radios.
• 2.4 GHz and 5 GHz radios now inherit the same stricter security rules as 6 GHz.
• This may prevent older Wi-Fi 4/5 clients (that lack WPA3 support) from connecting.

Alternate Next Best Method (7.20)

To improve legacy device compatibility, firmware 7.20 introduces an alternate conversion approach:

• On 2.4 GHz and 5 GHz, transition mode can still be used where possible.
• On 6 GHz, transition modes remain strictly prohibited for maximum security.

This balance ensures that modern security is enforced while older clients retain connectivity on non-6 GHz bands.

Example Event Log Messages

When security configurations are adapted or rejected, APs generate clear event logs:

• dppsk disabled - reason: unsupported security option
• security adapted from WPA2-Personal to WPA3-Personal - reason: unsupported security option

This transparency helps administrators quickly understand and troubleshoot security enforcement actions.

Key Implications

• MLO is always on with 11be radios → all linked radios must follow strict WiFi Alliance security rules.
• To avoid MLO restrictions, admins must switch the radio mode back to 802.11ax.
• Unsupported security methods either disable the SSID entirely or are converted to compliant equivalents.
• Firmware 7.20’s alternate next best method provides better backward compatibility for mixed environments.

These updates reinforce Zyxel’s commitment to delivering WiFi 7 performance with strong security compliance, while still supporting real-world deployments that include legacy clients.

As part of the latest updates in the Zyxel Nebula 19.10 release, one of the key enhancements involves a fundamental change to the 2.4GHz radio mode configuration on our WiFi 7 (11BE) access points. This article breaks down the reasoning, implications, and what users can expect after upgrading to firmware version 7.20.

Why the Change Was Necessary

Despite leveraging transition mode (which broadcasts both WPA2 and WPA3 security profiles simultaneously), many legacy clients still face challenges connecting to WiFi 7 APs. These clients struggle to transition between WPA3 and WPA2, and Enhanced Open is not supported in transition mode under 11BE. As a result, a segment of older devices remains unable to connect reliably to the network.

The Solution: Switching 2.4GHz to 11AX

To address this, Zyxel has changed the default 2.4GHz radio mode from 11BE to 11AX on WiFi 7 APs. This shift serves a dual purpose:

(1) Improves compatibility with older security standards (e.g., WPA2)

(2) Avoids enabling MLO (Multi-Link Operation), which is mandatory in 11BE and

restricts the use of older methods.

Summary Before and After Firmware 7.20

Think of the 2.4GHz band as the "radio of last resort", optimized for legacy clients with limited support for newer technologies.

Impact on Different Deployment Modes

Standalone Mode

● Before 7.20: Factory reset APs revert to 11BE on 2.4GHz.

● After 7.20: Factory reset sets the radio mode to 11AX.

Nebula Cloud-Managed Mode

● 2.4GHz radio mode is changed from Auto to Auto up to 11AX.

● Device-level configurations reflect this change while retaining existing settings such

as channel width, DCS schedule, and DFS/client awareness.

Controller-Managed (ZLD) Mode

● Upgrading the ZLD firewall to firmware 5.40 forces the 2.4GHz radio from 11BE to

11AX.

● However, all other 2.4GHz settings revert to factory defaults—an unintentional

behavior currently under review.

USG Flex H-Series (UOS)

● GUI does not yet support manual configuration of radio settings.

● Upon upgrading APs to 7.20, 2.4GHz radios using 11BE will automatically switch to

11AX.

Important: Settings like channel width should remain unchanged in most modes—except for Controller-Managed Mode, where full reset occurs.

Considerations for WPA3 and Legacy Devices

While switching to 11AX enables support for older security protocols, WPA3 still requires 802.11ax or newer clients. Therefore, even under 11AX mode, WPA3 will not be usable by older legacy clients.

Known Issues and Workarounds

ZLD Controller Firmware Reset

● Issue: Upgrading to firmware 5.40 resets all 2.4GHz settings to default.

● Status: Not documented in original spec; currently treated as a known issue.

MAC Authentication and MLO

● Current Status:

Not officially confirmed. Under investigation.

For those managing WiFi 7 deployments or planning firmware upgrades, it’s important to:

1. Audit your current 2.4GHz configurations.
2. Understand how the firmware 7.20 upgrade will impact default settings.
3. Be mindful of the behavior differences between standalone, cloud, and controller modes.
4. Plan around known issues (e.g., ZLD reset bug).

Stay tuned for more updates as Zyxel continues refining support for WiFi 7 features and ensuring robust legacy client compatibility.

As part of the enhancements in Zyxel’s Nebula 19.10 release, the Smart Mesh feature has undergone key updates to align with the new rules introduced by WiFi 7 (802.11be) and Multi-Link Operation (MLO). These changes improve the performance and consistency of Smart Mesh setups, especially when deploying WiFi 7 tri-radio access points.

This article explains what’s changed, why it matters, and how to optimize your Smart Mesh configurations moving forward.

Key Changes to Smart Mesh in 19.10

1. MLO Is Now Always Enabled with 11BE Radios

With the latest firmware:

• The 6GHz radio only supports 802.11be (WiFi 7) mode.
• MLO is mandatory when 11BE mode is active—disabling MLO is no longer an option for 6GHz radios.

Interface Changes:

• Previously, users could toggle MLO on/off when configuring Smart Mesh.
• Now, the on/off option for MLO is removed when the radio is set to 11BE.
• Instead, users simply select the participating radios for Smart Mesh; MLO is automatically handled based on the radio mode.

2. Improved UI Layout

To reduce confusion, the Smart Mesh settings page has been restructured:

• Uplink settings are grouped together.
• Downlink settings are grouped separately.
• This eliminates unclear sequences like “uplink, downlink, downlink, uplink,” streamlining the configuration process.

How MLO Works with Default Radio Modes

In firmware 7.20, the 2.4GHz radio defaults to 802.11ax (WiFi 6) mode. This impacts the kind of Smart Mesh connections that can be formed by default.

Default Capabilities:

If users forget to set all radios to 11BE, Smart Mesh will fall back to the highest compatible mode between APs. The AP with the lower radio mode will dictate the connection capabilities.

Auto-Adaptation and Compatibility Logic

• Repeater APs adapt to match the lowest shared standard across participating radios.
• Security settings are still based on the 11BE mode's requirements, even if the repeater downgrades temporarily for connectivity.
• Smart Mesh connections must mirror the radio set used by the downlink when establishing uplinks.

Real-World Example:

• A repeater connects to its downlink using 5GHz + 6GHz.
• It must use the same 5GHz + 6GHz combo when connecting to its uplink, even if all radios support 11BE.
• If 2.4GHz is not set to 11BE, full tri-radio MLO will not be possible.

Special Considerations for USG Flex and Legacy APs

Summary and Best Practices

• MLO cannot be disabled when 11BE is active.
• UI simplified: Users now just select the radios to use; MLO is applied automatically.
• For full tri-radio MLO, set 2.4GHz to 11BE on all APs.
• Mismatched radio modes cause fallback to dual-radio or single-radio connections.
• Always match downlink and uplink Smart Mesh radio paths.

With the ongoing rollout of WiFi 7 (802.11be) across Zyxel’s access points, new features have been introduced to improve security and enhance network diagnostics. One such feature is Beacon Frame Protection, which is automatically enabled on radios operating in 802.11be mode. In this article, we'll explain what beacon frame protection does, how it helps secure your network, and how to troubleshoot WiFi 7 management frames using remote capture.

Capturing WiFi 7 Management Frames with Remote Capture

Before diving into beacon protection, here’s a tip for those needing to analyze WiFi 7 management traffic for support or diagnostics.

Zyxel APs support a feature called Remote Capture, which allows you to collect wireless traffic directly from the air and forward it to a nearby PC running Wireshark. This is particularly useful because management frames (like beacons and probes) only exist on the wireless medium—they do not traverse Ethernet.

A Common Issue with Capturing WiFi 7 Frames

When capturing WiFi 7 management frames directly, users may encounter "malformed packets" in Wireshark. These packets are typically beacon frames containing WiFi 7-specific attributes, such as:

• Reduced Neighbor Report
• RSN Extension
• HE Capabilities

These malformed displays result from limitations in how current tools interpret WiFi 7 metadata—not necessarily from a defect in Zyxel APs.

Recommended Capture Setup

To properly capture WiFi 7 management frames:

1. Deploy Two WiFi 7 APs:
   • AP01: Provides WiFi service.
   • AP02: Set to the same channel as AP01 for passive sniffing.
2. Client Device:
   • Connects to AP01 using WiFi 7.
3. Wireshark PC:
   • Connected via remote capture to AP02.
   • Captures over-the-air traffic between the client and AP01.

This setup allows AP02 to observe beacon frames with full WiFi 7 attributes and forward them in real-time to the diagnostic PC.

What Is Beacon Frame Protection?

Beacon Frame Protection is a security enhancement introduced with 802.11be that helps protect clients from rogue AP spoofing and denial-of-service (DoS) attacks using falsified beacons.

How It Works

When enabled, a Message Integrity Code (MIC) is embedded within each beacon frame. Post-association clients use this MIC to verify that future beacons are indeed from the legitimate AP.

Key elements used to calculate the MIC:

• SSID Name
• BSSID (AP’s MAC address)
• Timestamp
• Sequence Number
• GTK (Group Temporal Key, obtained after association)

Why It Matters

With beacon frame protection:

• Clients reject spoofed beacons from rogue APs that try to mimic legitimate AP parameters but cannot generate valid MICs.
• Each MIC is dynamically generated based on the continuously updating timestamp and sequence number.
• Attackers cannot forge valid MICs unless they possess the GTK, which is only distributed during secure association.

Real-World Example

Let’s simulate a typical secure environment:

1. AP broadcasts SSID “OfficeWiFi” with beacon frame protection enabled.
2. Client associates and obtains the GTK.
3. AP begins sending beacon frames with dynamic MICs.
4. Rogue AP attempts to spoof the original beacon but lacks:
   • Accurate timestamp and sequence number
   • GTK for MIC generation

The client, detecting a mismatch in MIC, discards the spoofed beacon—preventing disruption or misinformation.

Compatibility and Client Impact

Good News: Non-WiFi 7 clients simply ignore the MIC field if they don’t support beacon frame protection.

This ensures no disruption to legacy devices or those connecting via older WiFi standards (e.g., 802.11n/ac/ax). The protection feature benefits only WiFi 7-capable clients and adds an extra layer of security without compromising backward compatibility.

Summary