Potential symptoms

Clients connected on 5 GHz may experience intermittent latency spikes, packet loss, and substantially reduced throughput while remaining associated. The degradation is especially apparent in latency-sensitive real-time video applications such as Microsoft Teams, where audio or video may pause, stutter, or become unusable. Webpages and other network applications may also load slowly or fail to complete. The condition can affect a subset of APs, persist after client counts fall, and temporarily clear after an AP restart or channel change.

Conditions

The issue is intermittent and may require prolonged operation before it appears. Engineering reproduced it on an MR46 serving eight 5 GHz clients with continuous bidirectional conferencing-like audio and video traffic while an adjacent-channel AP served 15 additional loaded clients, for 23 clients across the two APs. Reports also include high-density deployments and APs serving only a few clients, including periods without high channel utilization or obvious RF interference. Disabling downlink beamforming and OFDMA did not prevent the reported behavior. Engineering analysis associates the degradation with radio transmission failures during single-user transmit beamforming, but the exact initiating sequence and time to onset remain variable.

Resolution

Updated radio software corrects three recovery paths used during single-user transmit beamforming. It delays recovery until in-flight beamforming packets are transmitted, restores affected transmit parameters when their state becomes invalid, and recovers radio state when beamforming weights are unavailable. These corrections prevent the transmit path from remaining in the degraded state associated with sustained latency and packet loss.

Workarounds

Restarting the AP or changing its channel may temporarily restore performance; either action disconnects clients, and degradation may recur. Downgrading to a compatible MR 30 or MR 31 release has restored service in reported deployments. Recent engineering comparisons use MR 32.1.7 as an earlier baseline, but recovery on that release is not established for every affected deployment. Contact Meraki Support to select a compatible previously working release, confirm recovery, and obtain current mitigation guidance. Firmware changes interrupt wireless service. No configuration-only workaround is confirmed.

Confirmed affected models

MR44, MR46, MR56, MR57, CW9164I, CW9166I

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

• R33.1: 33.1.3

Back to release summary

Potential symptoms

Clients on an affected 5 GHz radio may experience multi-second latency and repeated packet loss, including when reaching the AP itself or the default gateway. The behavior can affect all clients connected to the same AP and interrupt real-time applications or ordinary data transfers.

Conditions

The confirmed failure involves 5 GHz DFS operation with OFDMA enabled and neighboring beacons that do not advertise tolerance for narrow-band OFDMA uplink responses. The AP automatically restricts those narrow responses as part of DFS coexistence handling; an actual radar detection or a manual configuration change is not required. With a 20 MHz uplink response bandwidth and clients using dynamic spatial-multiplexing power save, the affected scheduling path can retain more clients in a group than the permitted response allocations can accommodate. Invalid, overlapping allocations cause failed exchanges and load-dependent latency or packet loss. Reports include Windows clients, including a Wi-Fi 6E client; broader client applicability is not fully established. The behavior can persist with single-user transmit beamforming disabled and return within a few minutes of a reboot, distinguishing it from the separate beamforming-related latency issue MR-99882.

Resolution

The correction makes OFDMA client grouping respect the uplink response resources permitted by the radio's current coexistence restrictions. It reduces the affected group when the available response bandwidth cannot accommodate all scheduled clients, preventing invalid, overlapping allocations and the failed exchanges that delay data traffic. Normal DFS coexistence protections remain in effect.

Workarounds

Use a non-DFS channel for the affected 5 GHz radio. In Dashboard, go to Wireless > Configure > Radio Settings and either manually select a permitted non-DFS channel or exclude DFS channels from the assigned RF profile. For the RF-profile option, use "Change channels used by AutoChannel…" and "Deselect DFS Channels", then save. Confirm the radio is operating on a permitted non-DFS channel.

Channel changes can briefly interrupt client connectivity, so coordinate an appropriate maintenance window. Excluding DFS channels reduces the available channel pool and requires reviewing channel reuse and capacity; a manual override also gives up automatic channel selection for that radio. Rebooting the AP does not provide lasting recovery in the reported case, and disabling single-user transmit beamforming does not prevent the behavior. Contact Meraki Support for current mitigation guidance and assistance collecting evidence while the issue is present. See the Cisco Meraki DFS channel guidance for configuration steps.

Confirmed affected models

MR46, CW9176I

Confirmed affected versions

• R32.2: 32.2.5

Back to release summary

Potential symptoms

CW9164I and CW9166I APs may stop responding to SNMPv3 requests even though the SNMP service remains running. Monitoring systems receive timeouts, and local SNMP queries on the affected AP also fail.

Conditions

The issue has been observed intermittently on a subset of APs after sustained SNMP polling. Requests accumulate without being processed, but the exact polling sequence and time to onset have not been reproduced consistently.

Confirmed affected models

CW9164I, CW9166I

Confirmed affected versions

• R32.2: 32.2.1 to 32.2.5

• R33.1: 33.1.1 to 33.1.4

Potential workarounds

Rebooting an affected AP temporarily restores SNMP responses, but the issue may recur and the reboot interrupts wireless service. Contact Meraki Support to coordinate recovery and collect diagnostic information before rebooting when operationally practical.

Back to release summary

Potential symptoms

Wireless clients connected to a CW9178I may lose gateway connectivity for several seconds when one member of the AP's LACP uplink is disconnected, even though the other member remains connected. Testing includes approximately 4–5 seconds of interruption and up to six consecutive unanswered gateway pings before forwarding resumes.

Conditions

The AP's two Ethernet interfaces and upstream switch ports are configured as an LACP bundle. The issue occurs intermittently when one physical member is disconnected and link-loss notification reaches the AP's uplink handling later than the physical-link event. The surviving member remains available, but traffic does not immediately fail over to it.

Confirmed affected models

CW9178I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.1 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available on MR 32.2.5. Schedule LACP member maintenance during a maintenance window and allow for a brief client interruption. Contact Meraki Support for current failover guidance if traffic does not recover through the surviving member.

Back to release summary

Potential symptoms

APs may continue to broadcast Client Balancing load updates every five minutes even when Client Balancing is disabled. Packet captures may show UDP port 61111 broadcasts; these messages report load and channel-utilization information and do not by themselves initiate a client-steering action.

Conditions

The behavior is confirmed on CW9162I and CW9176D1 APs running the listed firmware. A periodic channel-utilization reporting path can publish a load update without checking whether Client Balancing is enabled.

Confirmed affected models

CW9162I, CW9176D1

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. The load updates do not themselves steer clients. Contact Meraki Support if the broadcasts conflict with monitoring or network policy.

Back to release summary

Potential symptoms

A client using MAC authentication may stop forwarding traffic several minutes after it roams between radios on the same AP, even though the client remains associated and has completed authentication.

Conditions

The issue is confirmed on a dual-band MAC-authentication SSID when a client reassociates between the 5 GHz and 2.4 GHz radios on the same AP. Delayed cleanup of the previous radio association can clear the authorization state used by the active association approximately five minutes after the roam.

Confirmed affected models

CW9178I; exact broader model scope is not fully established

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Downgrade the affected AP to a compatible MR 31 release. A firmware change restarts the AP and interrupts wireless service, so schedule it during a maintenance window and contact Meraki Support for deployment-specific guidance.

Back to release summary

Potential symptoms

Clients on RadSec-enabled SSIDs may fail to authenticate even though the AP has a valid certificate and its RadSec service appears to be running. The AP can receive local authentication requests without sending corresponding RadSec traffic over the wired uplink, leaving client connection attempts unanswered.

Conditions

The issue is reported intermittently on CW9166I APs using RadSec (RADIUS over TLS). The exact trigger and time to onset are not established. Server response behavior and RADIUS accounting support are also being checked, so the available evidence does not establish one cause for every reported authentication timeout.

Confirmed affected models

CW9166I

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Rebooting an affected AP has restored authentication service, but the reboot disconnects wireless clients and is not a permanent correction. Contact Meraki Support to coordinate recovery and collect diagnostic information before rebooting when operationally practical. No confirmed configuration workaround is documented.

Back to release summary

Potential symptoms

The Vusion electronic shelf-label (ESL) application on MR46 APs may repeatedly restart or lose its cloud connection, temporarily preventing label updates. Labels can retain stale information or display no pricing during an interruption. Reported recovery intervals are approximately one to two minutes; normal Wi-Fi service and AP cloud connectivity can remain available.

Conditions

Reports involve the Vusion BLE ESL application version 2.7.3.0. Events include application configuration changes, cloud-session disconnects, and failures to reach an authentication endpoint. The initiating cause remains under investigation; a companion log-recording process can also fail during application teardown, but that does not establish it as the cause of the ESL interruption.

Confirmed affected models

MR46

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

The application may recover automatically once cloud communication is restored. Contact Meraki Support and the ESL provider to check application status and required cloud connectivity when interruptions persist. No confirmed firmware or configuration workaround is available; reverting to an older ESL application has not provided reliable recovery in the reported deployment.

Back to release summary

Potential symptoms

Speaker groups may stop delivering audio to member speakers when their stream changes from unicast to multicast. In the reported Sonos setup, two speakers work, but adding a third causes audio to remain audible only on the group coordinator.

Conditions

Wi-Fi Personal Network (WPN) is enabled on the SSID, and the speakers belong to the same WPN group. The failure is associated with multicast distribution between group members. The exact forwarding failure remains under investigation; toggling multicast-to-unicast conversion did not restore the reported stream.

Confirmed affected models

Exact AP model scope is not fully established

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3 to 32.2.5

Potential workarounds

Disabling the Dashboard control "Wi-Fi Personal Network (WPN)" on the affected SSID has restored streaming. This removes WPN's per-user segmentation, so assess the isolation requirements before making the change and coordinate it with Meraki Support. Changes to the SSID can disrupt connected clients.

See Wi-Fi Personal Network documentation for the isolation behavior to assess before disabling WPN.

Back to release summary

Potential symptoms

A 6 GHz radio may report transmit power below the configured static value, potentially changing the intended coverage level. The observed cap varies with the operating channel and channel width.

Conditions

Reports involve CW9166I and CW9176D1 APs in the FCC regulatory domain. Engineering is validating the delivered power-limit tables and conducted versus radiated measurements. Recent CW9176 test results do not support a simple increase to the current limits; applicability of those results to the CW9166 reports remains under review.

Confirmed affected models

CW9166I, CW9176D1

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support to verify the AP model, regulatory domain, operating channel, channel width, and reported power before changing the RF design. Any coordinated channel or width change can interrupt clients and alter coverage or capacity.

Back to release summary

Potential symptoms

A teleworker VPN SSID may stop broadcasting after the primary concentrator becomes unavailable, preventing clients from connecting even though the configured secondary concentrator is reachable.

Conditions

The issue is intermittent and requires a teleworker VPN SSID with primary and secondary concentrators, active DHCP monitoring, and no associated clients or ordinary tunnel traffic. It is more readily reproduced when the AP restarts while only the secondary concentrator is available; the AP may continue reachability checks without completing the secure tunnel.

Confirmed affected models

Exact model scope is not fully established

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

• R33.1: 33.1.3

Potential workarounds

Restore reachability to the primary concentrator. If that is not possible, contact Meraki Support before changing the primary and secondary concentrator configuration; restarting the AP can reproduce the condition and is not a reliable recovery.

Back to release summary

Potential symptoms

Dashboard may show high 6 GHz non-802.11 utilization on CW9166I APs even when an external spectrum check finds no corresponding non-Wi-Fi interferer. Reports are most apparent during busy periods in dense deployments, and the measurement can give administrators a misleading indication of external interference.

Conditions

Reports involve dense 6 GHz deployments in the UK/ETSI regulatory domain. Sensitive radio energy-detection settings can count distant Wi-Fi transmissions as non-802.11 energy when their preambles cannot be decoded. The reporting behavior and suitable permanent threshold settings remain under validation.

Confirmed affected models

CW9166I

Confirmed affected versions

• R31.1: 31.1.8

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Contact Meraki Support to assess a temporary radio energy-detection adjustment. Limited field testing on MR 32.2.4 reduced the reported non-802.11 utilization, but the adjustment is lost after an AP reboot and firmware integration still requires validation. Corroborate the reported utilization with spectrum measurements before treating it as evidence of a non-Wi-Fi interferer.

Back to release summary

Potential symptoms

Clients using Local Auth with Opportunistic Key Caching (OKC) may be deauthenticated after approximately 2 hours and 59 minutes and then need to authenticate again. This interrupts client connectivity more frequently than the 12-hour session behavior reported with Fast Transition.

Conditions

The issue is reported on a Local Auth SSID where the authentication response sets a Session-Timeout of 10,740 seconds. The AP expires the client's cached authentication state at that interval. The exact AP model scope is not yet established.

Confirmed affected models

Exact AP model scope is not fully established

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Enabling the Dashboard "802.11r" control (Fast Transition) on the affected SSID has increased the reported session period to 12 hours. Validate client compatibility before enabling it and coordinate the SSID change with Meraki Support; configuration changes can interrupt service, and session expiry is delayed rather than eliminated.

Back to release summary

Potential symptoms

A wireless client may stop receiving usable downstream traffic while remaining associated. macOS clients may require a manual Wi-Fi reconnect, while some Windows clients detect the lost gateway reachability and reconnect automatically.

Conditions

The issue is confirmed on CW9172I and CW9176I during sustained same-AP traffic at 80 MHz channel width, often reproducing one to two minutes into a high-throughput test. A received four-address wireless frame can cause the AP radio to apply an inappropriate forwarding mode and subsequently send QoS data frames with both distribution-system direction bits set; meshing must be enabled for the affected path.

Confirmed affected models

CW9172I, CW9176I

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.6

• R32.2: 32.2.3 to 32.2.5, 32.2.5.1

Potential workarounds

Disable meshing to avoid the affected forwarding path, or disconnect and reconnect an impacted client to restore traffic temporarily. Disabling meshing removes wireless repeater capability and should be evaluated against deployment requirements.

Back to release summary

Potential symptoms

Clients may experience elevated 5 GHz latency, slow application performance, degraded or dropped voice and video calls, and interrupted file transfers. Recorded latency reaches hundreds of milliseconds to several seconds. Severity increases with client activity and can subside as activity decreases without rebooting the AP.

Conditions

The behavior is confirmed on a 5 GHz WLAN with a high concentration of 802.11ax clients and traffic that favors downlink Orthogonal Frequency Division Multiple Access (OFDMA), including small-payload traffic. Reports involve Windows clients using Intel Wi-Fi 6E AX211 adapters; applicability to other client types is not yet established. Client count alone does not determine whether the issue occurs: latency is observed with fewer than 20 associated clients as well as at higher counts. The underlying scheduling behavior remains under investigation.

Confirmed affected models

CW9176I

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.7

• R32.2: 32.2.5, 32.2.5.1

Potential workarounds

Contact Meraki Support to disable downlink OFDMA on the affected SSIDs using a Support-managed configuration. This mitigates the reported latency even with more than 30 active clients. Applying the change restarts the affected radios and briefly disconnects clients, so coordinate a suitable maintenance window. The mitigation disables simultaneous OFDMA downlink transmissions for those SSIDs and can reduce airtime efficiency; validate application performance after the change.

Back to release summary

Potential symptoms

MR44, CW9162I, and CW9172I APs may experience an unexpected reboot, disconnecting associated clients and temporarily making wireless service unavailable while the AP restarts.

Conditions

The issue occurs intermittently during client reassociation activity involving Protected Management Frames (PMF). Available engineering evidence associates it with incomplete cleanup of a previous protected client association during rapid reassociation, but the exact traffic sequence needed to trigger it is not fully characterized.

Confirmed affected models

MR44, CW9162I, CW9172I

Confirmed affected versions

• R32.1: 32.1.5 to 32.1.7

• R32.2: 32.2.1 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. The AP recovers by rebooting, but associated clients are disconnected during the restart. Contact Meraki Support if repeated reboots occur.

Back to release summary

Potential symptoms

CW9172I APs may experience an unexpected reboot, temporarily interrupting wireless connectivity for associated clients.

Conditions

A radio-firmware failure is associated with these reboots. Similar diagnostic signatures can represent different failure paths, and no specific customer configuration or traffic sequence is confirmed as a trigger.

Confirmed affected models

CW9172I

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support if reboots recur so the diagnostic signature can be confirmed and appropriate firmware guidance provided.

Back to release summary

Potential symptoms

MR44, CW9172I, and CW9176I APs may experience an unexpected reboot, disconnecting associated clients and temporarily interrupting wireless service while the AP restarts.

Conditions

Available engineering evidence includes more than one timer-related failure path. Some reports involve cleanup of Protected Management Frames (PMF) security-query timers, while other reports have a different timer-failure signature. A specific configuration or traffic trigger is not confirmed, and matching reboot reports require Support correlation.

Confirmed affected models

MR44, CW9172I, CW9176I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support if repeated reboots occur so the failure path can be identified and an appropriate software recommendation provided. Each reboot interrupts service to associated clients.

Back to release summary