Potential symptoms

Clients may fail to join an SSID even though the AP has only a small number of associated clients. Client event logs may show repeated association denials with status code 17, indicating that the AP believes it cannot accept another client while existing clients remain connected.

Conditions

Stale client state can cause the AP to advertise an incorrectly high station count in its beacons and probe responses, sometimes reporting hundreds of clients when fewer than ten are present. Reports were concentrated on 2.4 GHz SSIDs with client balancing disabled, although the exact model and band scope is not fully established.

Resolution

The AP now removes stale client records before calculating its advertised station count and available association capacity. This prevents an inflated client count from incorrectly blocking new associations.

Workarounds

No confirmed configuration workaround is available. If clients repeatedly receive association-denied events while the AP has a low client count, contact Meraki Support to confirm the signature and obtain an appropriate software recommendation.

Confirmed affected models

Wi-Fi 7 APs; exact model scope is not fully established

Confirmed affected versions

• R31.2: 31.2.5.1

Back to release summary

Potential symptoms

When a RADIUS session timeout expires, the client may not receive the expected deauthentication frame from the AP. The client can continue to appear connected until it sends additional traffic or starts a new authentication attempt, delaying the expected disconnect and reauthentication behavior.

Conditions

The issue affects WPA-Enterprise SSIDs that use the RADIUS Session-Timeout attribute. The AP begins the deauthentication process, but security-key cleanup can occur before the management frame is transmitted; both short and long configured timeout values can encounter the same sequence.

Resolution

The AP now waits for the deauthentication or disassociation frame to complete before removing the client's security keys. Clients therefore receive the expected session-expiration notification and can begin reauthentication without waiting for a later traffic failure.

Workarounds

No confirmed configuration workaround preserves the same RADIUS session-timeout behavior. If a client remains connected beyond its expected timeout, disconnecting and reconnecting the client forces a new authentication; contact Meraki Support if the behavior is frequent or policy-sensitive.

Confirmed affected models

MR57, CW9162I

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.2

Back to release summary

Potential symptoms

Dashboard may continue to show a client as associated after the client has left the coverage area, and the AP status LED can remain blue even when no client is present. The stale entry can inflate client counts and complicate troubleshooting, although it does not by itself indicate that client traffic is still flowing.

Conditions

The issue occurs when a client leaves without transmitting a disassociation frame and the AP later sends a deauthentication frame to remove it. The frame is sent, but the AP does not complete the corresponding local cleanup; clients that send a normal disassociation do not leave the same stale state.

Resolution

The AP now completes local client cleanup after an AP-originated deauthentication frame is processed. Dashboard association state and the AP status indication therefore return to the actual connected-client state.

Workarounds

Reconnecting the same client and then disconnecting it normally may clear the stale association. Restarting the AP also clears the state but disconnects all clients, so use a restart only during a suitable maintenance window.

Confirmed affected models

CW9176I

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.3

• R33.1: 33.1.1

Back to release summary

Potential symptoms

A client can join a protected SSID successfully but later disconnect during a periodic WPA key refresh. The client may show an EAPOL timeout and must reconnect or reauthenticate, producing an intermittent outage that can be specific to client implementations.

Conditions

During pairwise or group-key renewal, the AP can mark the first handshake message in a way that causes some clients to encrypt their final response before the AP is ready to decrypt it. Initial association succeeds; the failure appears only when an existing session refreshes its security keys.

Resolution

The AP now advertises the key-renewal handshake state correctly in the first message. Clients therefore send the final response using the expected key, allowing the refresh to complete without a timeout or disconnection.

Workarounds

Where security policy permits, increasing the periodic 802.1X reauthentication interval can reduce how often affected clients encounter the key-refresh sequence. This delays periodic credential revalidation and should be evaluated against the organization's authentication requirements.

Confirmed affected models

All APs

Confirmed affected versions

• R32: exact affected point-release range is not fully established

Back to release summary

Potential symptoms

Clients may be unable to authenticate on every RADIUS over TLS (RadSec)-enabled SSID served by an AP, including SSIDs whose authentication servers are configured correctly. Dashboard may report that a configured authentication server is unknown or unreachable.

Conditions

The issue occurs when at least one RadSec server is configured with a fully qualified domain name (FQDN) that the AP cannot resolve. In affected firmware, one invalid server entry can prevent the shared RadSec proxy from starting, affecting other RadSec-enabled SSIDs on the same AP. The exact affected-model scope is not fully established.

Resolution

The AP now excludes RadSec server entries whose addresses cannot be resolved while continuing to start the shared RadSec proxy for valid server entries. Other RadSec-enabled SSIDs on the same AP can continue authentication when at least one external RadSec server is configured with a valid IP address or resolvable FQDN. When an SSID has multiple servers, normal RADIUS timeout and failover behavior still applies to an invalid entry.

Workarounds

Correct or remove every unresolvable RadSec server FQDN so that all configured server names resolve successfully. Removing a server reduces authentication redundancy, and changing authentication-server settings can interrupt new client connections, so make the change during a suitable maintenance window and contact Meraki Support if the correct configuration remains unavailable.

Confirmed affected models

Exact model scope is not fully established

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.3

Back to release summary

Potential symptoms

An AP may unexpectedly reboot after Proactive PCAP consumes increasing amounts of memory. Each restart disconnects associated clients and temporarily interrupts wireless service, and the behavior can recur while automatic captures remain enabled.

Conditions

The issue occurs when Network-wide > Intelligent Captures > Proactive PCAP is enabled and automatic transmit packet captures run over time. Capture-related memory can grow rapidly until the AP exhausts available memory. Proactive PCAP is disabled by default, and the exact broader model scope is not fully established.

Resolution

Updated Wi-Fi driver handling prevents packet-capture data from accumulating until memory is exhausted. In validation, 29 APs running the corrected software with Proactive PCAP enabled did not reproduce the out-of-memory restart.

Workarounds

In Dashboard, go to Network-wide > Intelligent Captures > Proactive PCAP and select Disable the auto capture for all devices. This stops automatic captures and has prevented the repeated memory exhaustion, but it removes Proactive PCAP visibility for all devices in the network until the feature is re-enabled.

Confirmed affected models

MR36, MR36H, CW9166I; exact broader model scope is not fully established

Confirmed affected versions

• R31.1: exact affected point-release range is not fully established

• R31.2: 31.2.1 to 31.2.5

• R32.1: 32.1.4, 32.1.6

Back to release summary

Potential symptoms

An MR76 AP may gradually consume available memory and eventually reboot when the system can no longer allocate memory. The reboot temporarily disconnects clients, and the behavior may recur after the AP has been running for another extended period.

Conditions

The memory increase develops over time and was not attributable to a single visibly high-memory process or a specific customer traffic pattern. Disabling application-visibility and accounting features did not prevent the growth; confirmed reports involved MR76 APs, while MR52 APs on the same networks did not show the behavior.

Resolution

The firmware corrects the memory leak responsible for the gradual resource loss. The AP now releases the affected resources during normal operation instead of accumulating them until an out-of-memory restart occurs.

Workarounds

Restarting the AP temporarily returns memory use to normal but interrupts wireless service and does not prevent the leak from recurring. Schedule any restart during a maintenance period and contact Meraki Support if memory growth or repeated reboots continue.

Confirmed affected models

MR76

Confirmed affected versions

• R31.1: 31.1.7 to 31.1.8

• R32.1: 32.1.4, 32.1.5

Back to release summary

Potential symptoms

Starting or running a wireless packet capture may disconnect clients and cause the AP to unexpectedly reboot.

Conditions

Affected Wi-Fi 6 and Wi-Fi 6E models while taking a packet capture. Reports often involved active traffic and 10 or more associated clients; both short and longer captures have reproduced the failure.

Resolution

Updated Wi-Fi radio handling corrects the transmit-statistics cleanup used by the packet-capture monitoring path, preventing the invalid memory access and resulting reboot.

Workarounds

Avoid AP wireless packet captures on affected APs when possible. If a capture is required, contact Meraki Support before starting it.

Confirmed affected models

• MR28, MR36, MR44, MR46, MR56, MR76, MR86

• CW9164I, CW9166I, MR57

Confirmed affected versions

• R32.1: 32.1.7

• R32.2: 32.2.3

• R33.1: 33.1.1

Back to release summary

Potential symptoms

An AP may unexpectedly reboot after a wireless-service log rapidly fills its temporary storage. Clients are disconnected during the restart, and repeated log growth can produce recurring wireless outages.

Conditions

Under memory pressure, an internal control operation can repeatedly fail and generate log messages faster than normal log rotation can reclaim space. Confirmed reports span several AP generations and are not tied to a single customer configuration or traffic pattern.

Resolution

The wireless service now stops the failed operation when memory is unavailable instead of retrying it indefinitely and flooding the log. Temporary storage remains available, preventing the storage-exhaustion reboot associated with this sequence.

Workarounds

No proactive customer configuration workaround is confirmed because the triggering memory-pressure sequence is intermittent. Contact Meraki Support if an AP repeatedly reboots.

Confirmed affected models

MR46, CW9162I, CW9178I

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.3

Back to release summary

Potential symptoms

An MR57 AP may unexpectedly reboot, temporarily disconnecting clients and making its SSIDs unavailable while the AP and radios restart. Repeated occurrences can present as intermittent wireless service interruptions.

Conditions

The issue is caused by a specific Wi-Fi radio error that can occur during normal operation. No customer configuration, client type, or repeatable traffic trigger has been established for the confirmed variant.

Resolution

The updated Wi-Fi radio software corrects the identified failure path. The AP can complete the affected radio operation without raising the exception and forcing a system recovery.

Workarounds

No confirmed configuration workaround is available. Contact Meraki Support if an MR57 repeatedly reboots so the event can be matched to the corrected variant and the appropriate firmware recommendation provided.

Confirmed affected models

MR57

Confirmed affected versions

• R32.1: 32.1.6

Back to release summary

Potential symptoms

A CW9172I AP may unexpectedly reboot, disconnecting clients and making wireless service unavailable while the AP restarts. Frequent occurrences can cause repeated short outages at the affected AP.

Conditions

The failure occurs intermittently while the radio processes and cleans up monitoring data. No customer configuration or manual packet-capture action has been confirmed as a prerequisite, so it can appear during otherwise normal AP operation.

Resolution

The radio software now cleans up queued monitoring data safely when the receive path is stopped or restarted. This prevents the invalid state that caused the AP to reboot during the affected sequence.

Workarounds

No confirmed configuration workaround is available. Contact Meraki Support if a CW9172I repeatedly reboots so the event signature can be confirmed and an appropriate software recommendation provided.

Confirmed affected models

CW9172I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

Back to release summary