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

A client-serving radio may report close to 100% non-Wi-Fi channel utilization and stop responding to client probe or authentication requests. New clients cannot join, and existing clients may lose service, even though the AP's scanning radio reports normal channel conditions.

Conditions

The issue occurs intermittently on affected APs and can affect either the 2.4 GHz or 5 GHz client-serving radio. Two radio failure variants were identified; changing the channel recovers some occurrences, while others persist until the radio or AP is restarted.

Resolution

The Wi-Fi radio handling now corrects both identified failure variants that could leave a client-serving radio in a falsely busy state. The radio can continue normal beaconing, probe-response, and client-authentication operation instead of remaining unavailable until recovery.

Workarounds

Changing the affected radio's channel may temporarily restore service for one failure variant. If service does not recover, restart the AP; either action disconnects clients and should be scheduled during non-critical hours when possible.

Confirmed affected models

MR46, MR56, MR57, CW9164I, CW9166I

Confirmed affected versions

• R32.1: 32.1.4 to 32.1.7

Back to MR Access Point 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

Potential symptoms

An affected AP may unexpectedly reboot, disconnecting clients and temporarily making wireless service unavailable while the AP restarts.

Conditions

The issue is confirmed on MR44 and CW9176I APs running 32.2.4. Available fleet evidence indicates that the signature is rare, and no specific customer configuration or traffic sequence has been confirmed as the trigger.

Resolution

Firmware in 33.1.2 includes the underlying networking-path correction, preventing the identified invalid packet-buffer operation that caused the kernel panic.

Workarounds

No confirmed configuration workaround is available on affected firmware. Upgrade to 33.1.2 or later; contact Meraki Support if an AP continues to report the same watchdog signature after upgrading.

Confirmed affected models

MR44, CW9176I

Confirmed affected versions

• R32.2: 32.2.4

Back to MR Access Point summary

Potential symptoms

An associated client may remain shown as connected but stop passing downstream and bidirectional traffic approximately 30 seconds after roaming between radios on the same AP. Disconnecting and reconnecting the client restores service.

Conditions

The confirmed case uses a non-802.11be client that negotiates Galois/Counter Mode Protocol (GCMP) on an 802.11be-enabled WPA3-Enterprise SSID, then roams between the 5 GHz and 6 GHz radios on the same AP. Cleanup of the previous radio occurs after the roam and incorrectly removes the active client encryption state on the new radio; the behavior is confirmed with 802.11r both enabled and disabled, while other security modes have not been fully characterized.

Potential workarounds

Disable 802.11be on the affected SSID to avoid the triggering client and radio combination, or temporarily use 32.2.4. Disabling 802.11be removes Wi-Fi 7 capabilities from the SSID, and changing firmware requires a maintenance window.

Confirmed affected models

CW9178I

Confirmed affected versions

• R33.1: 33.1.1, 33.1.2

Back to MR Access Point summary

Potential symptoms

After an upstream power loss or ungraceful reboot, an MR36 may boot with an amber-blinking LED and remain unable to communicate over its wired uplink. Clients cannot obtain normal network service through the AP until the Ethernet link state is replayed or the port is cycled.

Conditions

The confirmed setup powers an MR36 from an MX68 and reproduces the failure on roughly 15–25% of repeated ungraceful power cycles. A link-up event can arrive during the AP's forwarding-configuration reload and be discarded as stale, leaving the wired transmit queues disabled even though physical carrier is present; 32.1.3 is confirmed unaffected.

Confirmed affected models

MR36

Confirmed affected versions

• R32.1: 32.1.4 to 32.1.7

• R32.2: 32.2.1 to 32.2.4

• R33.1: 33.1.1, 33.1.2

Potential workarounds

Disable and re-enable Power over Ethernet (PoE) on the supplying switch or security appliance port, or administratively bounce the Ethernet port. Either action interrupts AP power or uplink connectivity and should be performed during a maintenance window; contact Meraki Support if remote recovery is not available.

Back to MR Access Point summary

Potential symptoms

Nearby clients and APs may stop seeing an affected CW9166I's SSIDs on either 5 GHz or, more commonly, 6 GHz, preventing new client associations on that band. Local AP counters can continue to report successful beacon transmission even though over-the-air captures do not observe the frames, and rebooting may not restore service.

Conditions

The issue is intermittent across APs and bands and has been confirmed in a low-utilization deployment, but the triggering sequence is not yet characterized. Host services and virtual interfaces remain up while adjacent and external captures fail to observe the expected beacons; available evidence has not yet established whether accompanying radio resets are causal.

Confirmed affected models

CW9166I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.4

• R33.1: 33.1.1, 33.1.2

Potential workarounds

For instances affecting the 6 GHz flex radio, configure the RF profile for dual 5 GHz operation as a temporary mitigation. This removes 6 GHz capacity and may not address a 5 GHz occurrence; contact Meraki Support for affected 5 GHz radios or when the mitigation is unsuitable.

Back to MR Access Point summary

Potential symptoms

Clients associated on 5 GHz may be disconnected shortly after the AP applies an updated Automated Frequency Coordination (AFC) power table. Affected clients may reconnect or move to another available band, but the event interrupts active sessions.

Conditions

The issue is confirmed on CW9178I APs operating in 6 GHz Standard Power mode while serving clients on 5 GHz. It follows a successful periodic or manually initiated AFC refresh; the exact radio and client sequence that causes the 5 GHz disruption remains under investigation.

Potential workarounds

No confirmed configuration workaround is available. Avoid manually refreshing AFC unless needed for troubleshooting, and contact Meraki Support if periodic AFC updates repeatedly interrupt client service so current mitigation guidance can be provided.

Confirmed affected models

CW9178I

Confirmed affected versions

• R32.2: 32.2.3

• R33.1: 33.1.2

Back to MR Access Point summary

Potential symptoms

A CW9164I may enter a repeated reboot cycle after upgrading to r33, leaving 6 GHz wireless service unavailable and repeatedly interrupting the other radios during startup. The behavior begins when the AP validates the 6 GHz SSID group configuration.

Conditions

Two 6 GHz SSIDs in the same Multiple Basic Service Set (MBSS) group use different group-management ciphers, such as WPA3-Personal on one SSID and WPA3-Enterprise 192-bit mode on another. In 802.11ax operation, beacon protection is disabled by default, but affected firmware incorrectly requires the ciphers to match even when beacon protection is not active.

Potential workarounds

Use any one of these temporary mitigations: disable 6 GHz, place the WPA3-Enterprise 192-bit SSID in a separate MBSS group with help from Meraki Support, or temporarily use 32.2.4. These options respectively remove 6 GHz service, change SSID grouping, or require a firmware maintenance window.

Confirmed affected models

CW9164I

Confirmed affected versions

• R33.1: 33.1.1, 33.1.2

Back to MR Access Point summary

Potential symptoms

A CW9163E may enter a repeated reboot cycle shortly after it is switched to site survey mode, making the local status page unavailable and preventing the survey. Returning the AP to client-serving mode recovers it, but entering site survey mode again retriggers the behavior.

Conditions

The issue is confirmed when a CW9163E uses the UK regulatory domain and enters site survey mode, even when 6 GHz was disabled in the normal client-serving configuration. Site survey defaults incorrectly enable the 6 GHz radio without a valid Automated Frequency Coordination (AFC) channel, so the radio cannot start and the watchdog restarts the AP; other regulatory domains without outdoor 6 GHz authorization may also be affected but are not confirmed.

Confirmed affected models

CW9163E

Confirmed affected versions

• R32.1: 32.1.7

• R32.2: 32.2.4

• R33.1: 33.1.1, 33.1.2

Potential workarounds

Keep the AP in client-serving mode and do not use site survey mode in the affected regulatory environment. If the AP is already rebooting, factory-reset it to return to client-serving mode; this erases local configuration and requires reconfiguration, so contact Meraki Support before proceeding.

Back to MR Access Point summary

Potential symptoms

An affected Wi-Fi 7 AP may unexpectedly reboot, temporarily interrupting wireless service for associated clients. The confirmed signature occurs in the radio subsystem and may be reported alongside other, unrelated reboot reasons, so Support correlation may be required.

Conditions

The issue is confirmed on CW9171I, CW9172H, and CW9172I during normal operation and was observed once for the documented signature on 32.2.4. Engineering analysis found a rare scheduling condition in which a radio diagnostic resource can be held long enough to trigger the radio watchdog; no customer configuration or traffic trigger is currently established.

Potential workarounds

No confirmed configuration workaround is available. The AP recovers by rebooting automatically; contact Meraki Support if repeated reboots occur so the specific signature can be distinguished from other reboot causes.

Confirmed affected models

CW9171I, CW9172H, CW9172I

Confirmed affected versions

• R32.1: 32.1.7

• R32.2: 32.2.4

• R33.1: 33.1.1, 33.1.2

Back to MR Access Point summary

Potential symptoms

An affected 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 issue affects the separate scanning radio used by the listed Wi-Fi 6 APs and has been observed intermittently across the confirmed firmware versions. Engineering analysis indicates a radio hardware-and-firmware interaction, but the exact event that triggers the assertion and its recurrence interval are not fully established.

Confirmed affected models

MR36, MR36H, MR44, MR46, MR46E, MR56, MR76, MR86

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.2 to 32.2.4

• R33.1: 33.1.1, 33.1.2

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support if a listed AP repeatedly reboots so the event signature can be confirmed and current software guidance can be provided.

Back to MR Access Point summary

Potential symptoms

An affected AP may unexpectedly reboot, disconnecting clients and making its SSIDs unavailable while the AP restarts. Repeated occurrences can cause intermittent wireless outages at APs using the listed models and firmware.

Conditions

The identifying radio report is associated with duplicate cleanup activity for the same wireless flow during radio processing. The exact customer configuration or traffic sequence that produces the duplicate operation remains under investigation, so there is no reliable action an administrator can use to predict or reproduce it.

Confirmed affected models

MR44, MR57, CW9166I, CW9166D1

Confirmed affected versions

• R32.1: 32.1.4 to 32.1.7

• R32.2: 32.2.3 to 32.2.4

• R33.1: 33.1.1, 33.1.2

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support if an affected AP repeatedly reboots so the event signature can be confirmed and current mitigation or firmware guidance provided.

Back to MR Access Point summary

Potential symptoms

Wireless clients may lose data connectivity after a previously used IP address is reassigned. The Campus Gateway can retain deleted client records, causing its active-client count to grow and a newly connected client using a stale address to be treated as a duplicate and removed from the AP.

Conditions

The confirmed condition is a multi-network Campus Gateway deployment in which AP networks run 32.2 firmware while the Campus Gateway runs 33.1 firmware. Client deletion requests from the older AP software omit anchoring information expected by the newer gateway software, so the gateway may reject those requests and retain stale client and IP state; the affected AP model scope is not fully established.

Potential workarounds

Keep the Campus Gateway and all AP networks it serves on matching firmware versions. In an affected mixed-version deployment, either upgrade the AP networks to the same 33.1 release as the gateway or downgrade the gateway to 32.2.3; either action reloads infrastructure and should be performed during a maintenance window.

Confirmed affected models

Campus Gateway

Confirmed affected versions

• R32.2: 32.2.3, 32.2.4

• R33.1: 33.1.1, 33.1.2

Back to Campus Gateway summary