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

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 release summary

Potential symptoms

APs may change channel or transmit power approximately every 30 minutes, causing repeated client connectivity interruptions.

Conditions

Meshing is enabled. The AP can treat its own mesh transmissions as strong external interference, causing RRM to make unnecessary channel or transmit-power changes during periodic optimization.

Resolution

Firmware now filters the AP’s own mesh-interface observations before they reach the Radio Resource Management calculation, preventing them from driving unnecessary channel or transmit-power changes.

Workarounds

Disable wireless meshing on the affected network when mesh connectivity is not required. Changing the mesh setting, including disabling or re-enabling it, disrupts service on the AP and should be performed only during non-critical hours.

Confirmed affected models

• All APs

Confirmed affected versions

• R32.1: 32.1.1 to 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

Clients on 5 GHz may remain associated but experience severe packet loss and high latency, making web browsing and other applications slow or unusable. The impairment can be intermittent and may affect only one AP or radio while nearby service appears normal.

Conditions

The issue occurs on MR46 and MR56 APs when incorrect clear-channel assessment thresholds cause the radio to defer or mishandle transmissions even without a corresponding increase in actual interference. Changing the radio channel can temporarily clear the condition.

Resolution

The Wi-Fi radio handling now applies the correct clear-channel assessment thresholds. This allows the AP to evaluate channel activity accurately and transmit normally, preventing the excessive latency and packet loss caused by the incorrect threshold values.

Workarounds

Changing the affected 5 GHz radio's channel may temporarily restore service. A channel change disconnects clients during the transition and may alter coverage or channel-planning behavior, so use it as a temporary measure and contact Meraki Support if the issue recurs.

Confirmed affected models

MR46, MR56

Confirmed affected versions

R32.1: 32.1.4, 32.1.5

Back to release summary

Potential symptoms

APs may continue beaconing but stop replying to probe requests and open-authentication frames, preventing clients from discovering or joining SSIDs on one or more radios.

Conditions

The issue is introduced in 32.1.6 and can leave a radio beaconing while no longer transmitting probe responses or open-authentication replies. Reports occurred after roughly 2 to more than 20 hours.

Resolution

Wi-Fi radio handling now clears the unexpected filter state for the AP's own BSSID, allowing queued probe responses and open-authentication replies to be transmitted normally.

Workarounds

Rebooting the AP or changing the affected radio's channel temporarily restores service. Either action disrupts connected clients and should be scheduled during non-critical hours when possible.

Confirmed affected models

• Wi-Fi 6: MR28, MR46, MR56, MR76

• Wi-Fi 6E: CW9162I, CW9164I, MR57

• Wi-Fi 7: CW9171I, CW9172I, CW9176I, CW9178I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

Dashboard wireless-latency values may be zero, unavailable, or shown as insufficient data on client, AP, and Performance Health pages.

Conditions

A Wi-Fi 7 AP has at least one active SSID using GCMP-256 or SAE-EXT while 802.11be is disabled. A radio-software change incorrectly treated the control used to enable latency capture as a Wi-Fi 7-only setting. When the AP operated in Wi-Fi 6 mode, the radio rejected the enable request and latency collection did not start.

Resolution

Radio software now handles the latency-capture control independently of Wi-Fi 7-specific controls, so the enable request is accepted in both Wi-Fi 6 and Wi-Fi 7 operation.

Workarounds

Enable 802.11be, or avoid GCMP-256 and SAE-EXT on active SSIDs while 802.11be is disabled. Changing radio mode or SSID security can disrupt clients and should be scheduled during non-critical hours; use alternative security settings only when permitted by the organization's security policy.

Confirmed affected models

• CW9176I, CW9178I

Confirmed affected versions

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

The Electronic Shelf Label (ESL) application may remain offline after the AP loses and regains cloud connectivity.

Conditions

After a connectivity failure causes the ESL application to stop, incomplete cleanup can leave the stopped application container in place and block its restart.

Resolution

Firmware now completes cleanup of a stopped application container, allowing the ESL service to restart normally.

Workarounds

Rebooting the AP clears the stopped application state and restores the ESL application temporarily. The reboot interrupts wireless service and should be scheduled during non-critical hours.

Confirmed affected models

• CW9164I

Confirmed affected versions

• R31.1: 31.1.7, 31.1.7.1

• R32.1: 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

APs may report excessive false Dynamic Frequency Selection (DFS) events and repeatedly leave DFS channels even when no radar is present. This can concentrate radios on UNII-1 channels, increasing co-channel interference, reducing client throughput, and disrupting clients during channel changes.

Conditions

MR46 or MR86 operating on DFS/UNII-2c channels.

Resolution

Updated Wi-Fi radio handling improves radar-event detection so non-radar activity is less likely to trigger an unnecessary DFS channel change.

Workarounds

Enable AI Channel Planning in Dashboard. It monitors DFS hits per AP and channel and temporarily places frequently affected channels on a per-AP Channel Avoid List. This can reduce repeated use of channels producing false DFS events. Alternatively, manually exclude affected DFS channels in the RF profile. Either approach reduces available 5 GHz spectrum and should be used only where the resulting channel plan is acceptable.

Confirmed affected models

• MR46, MR86

Confirmed affected versions

• R31.1: 31.1.7.1

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

A wireless client may be unable to reach a wired client on the same VLAN even when the configured Adaptive Policy permits the traffic.

Conditions

Adaptive Policy is enabled and a wireless client communicates with a wired client on the same VLAN under a protocol-specific policy. Address-resolution traffic can be denied before the allowed IP session begins.

Resolution

Address-resolution traffic is now handled separately from protocol-specific IP policy checks, allowing same-VLAN communication while preserving policy enforcement for subsequent traffic.

Workarounds

Place the wired and wireless clients on different VLANs, where routing occurs before the Adaptive Policy check. This changes network segmentation and may require corresponding routing and policy updates.

Confirmed affected models

• All APs

Confirmed affected versions

• R31.1: 31.1.6 to 31.1.8

• R32.1: 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

Dashboard may report a Config fetch error that later clears after the AP retries and successfully downloads its configuration.

Conditions

On MR44 APs after a firmware upgrade, a transient secure configuration-download failure can raise the alert, but a later retry normally succeeds. The issue is not confirmed on other AP models.

Resolution

The secure configuration-fetch path now retries without creating the misleading alert when the transient download condition occurs.

Workarounds

The alert generally clears after the AP retries without intervention. Contact Meraki Support if it persists or configuration changes are not applied.

Confirmed affected models

• MR44

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.1 to 32.2.3

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

A device connected to an MR36H LAN port may show no Ethernet link or may lose link after operating normally for days or weeks. The attached room or hospitality device becomes unreachable even though 1 Gbps devices connected to the same AP can continue to link normally.

Conditions

The issue is associated with some 100 Mbps devices that do not complete Ethernet auto-negotiation reliably when connected directly to an MR36H LAN port. It can occur on initial connection or after an extended period, and reseating the cable or power-cycling the endpoint does not always restore service.

Resolution

Meraki Support can apply a port override that fixes the affected LAN port at 100 Mbps full duplex, avoiding the unsuccessful auto-negotiation sequence. This release does not automatically apply the override because it is appropriate only for affected 100 Mbps link partners.

Workarounds

Contact Meraki Support to force the affected MR36H LAN port to 100 Mbps full duplex. Where the topology permits, placing a compatible Ethernet switch between the AP and the 100 Mbps device can also provide a stable negotiated link, but it adds equipment and another powered dependency.

Confirmed affected models

MR36H

Confirmed affected versions

• R31.1: 31.1.7

• R32.1: 32.1.6

Back to release summary

Potential symptoms

A client may be assigned to the wrong VLAN even though RADIUS returns the expected named VLAN.

Conditions

Named VLAN assignment is supplied by RADIUS and the Dashboard control "Enable Named VLAN for use with RADIUS" is enabled, but the separate named-VLAN tagging setting on the SSID is disabled. The AP can ignore the VLAN name returned by RADIUS.

Resolution

Named VLAN processing now honors the Dashboard "Enable Named VLAN for use with RADIUS" control and applies the VLAN name returned by RADIUS.

Workarounds

Use a numeric VLAN ID from RADIUS, or enable named-VLAN tagging in the SSID Access Control settings in addition to the RADIUS named-VLAN control. Either option requires an SSID or RADIUS configuration change.

Confirmed affected models

• All APs

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.2, 32.2.3

Back to release summary

Potential symptoms

Clients can complete 802.1X authentication but fail to receive the expected Cisco ISE splash-page redirect. Depending on the configured authorization policy, the client may remain unable to reach its intended network resources even though Dashboard shows a successful authentication.

Conditions

The issue can appear after an upgrade on SSIDs using Central Web Authentication with a Cisco ISE splash page. A legacy per-client authorization value retained on the AP can take precedence over the current SSID policy and incorrectly suppress splash enforcement.

Resolution

The AP now removes the obsolete authorization override and applies the current SSID splash policy after authentication. Authenticated clients are redirected to Cisco ISE as configured instead of retaining the stale no-splash state.

Workarounds

Meraki Support can clear the retained authorization state so the client receives the current splash policy on its next authentication. The client must reconnect and authenticate again, and the behavior may return until fixed firmware is installed.

Confirmed affected models

All APs

Confirmed affected versions

R32.1: 32.1.6

Back to release summary

Potential symptoms

After a fast roam, a client may remain associated and appear successfully authenticated but lose access to network resources. The client can remain in this blocked state until it performs a full authentication or its session is cleared.

Conditions

The issue requires an 802.1X SSID with 802.11r fast roaming and a Cisco ISE splash-page authorization policy. When the client reuses its authentication state at the destination AP, the AP can fail to recreate the client's existing no-splash authorization state and incorrectly place the client behind splash enforcement.

Resolution

The destination AP now preserves the client's splash authorization state during an 802.11r roam. Clients that were already authorized can continue passing traffic immediately after the roam instead of being blocked until a full reauthentication.

Workarounds

Disabling the Cisco ISE splash-page policy avoids the incorrect post-roam enforcement but removes the splash authorization experience for all clients on the SSID. Contact Meraki Support before changing the authentication design, or clear and reconnect an affected client to restore service temporarily.

Confirmed affected models

MR46, CW9178I

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.3

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

Clients can remain associated, obtain an IP address, resolve DNS names, and respond to basic connectivity tests while web pages intermittently stall or load only partially. The problem affects NAT-mode wireless traffic; bridge-mode wireless traffic and wired clients can continue to operate normally.

Conditions

The issue was reproduced on CW9178I APs using Meraki NAT-mode SSIDs, particularly when several clients browse different websites at the same time. Clients remain associated and retain working DHCP, DNS, and basic IP reachability; bridge-mode SSIDs and wired clients on the same network are not affected by this issue.

Resolution

This release changes NAT-mode traffic handling so the affected behavior is avoided by default. APs use the established NAT-mode forwarding behavior, preventing the intermittent application stalls without requiring an AP-specific configuration change.

Workarounds

No workaround or Support-applied configuration is required after upgrading to this release. For APs that must remain on an affected earlier release, contact Meraki Support for a temporary configuration change; upgrading is the recommended resolution.

Confirmed affected models

CW9178I

Confirmed affected versions

R32.1: 32.1.6

Back to release summary

Potential symptoms

A wireless client can remain associated, retain a valid IPv4 address, and appear online in Dashboard while all IPv4 traffic is blocked. The loss of connectivity can look like a silent client outage because association and DHCP state still appear healthy.

Conditions

The issue requires a Campus Gateway deployment with Mandatory DHCP enforcement and a client that frequently changes its IPv6 link-local privacy address. The IPv6 address update can incorrectly remove the client's otherwise valid IPv4 forwarding state.

Resolution

Campus Gateway client tracking now maintains IPv4 and IPv6 state independently during IPv6 address changes. Updating an IPv6 privacy address no longer removes a valid IPv4 binding or interrupts the client's IPv4 traffic.

Workarounds

Turning Wi-Fi off and back on at the client forces a new association and rebuilds the IPv4 binding, temporarily restoring connectivity. This interrupts the client's active sessions and the issue can recur if IPv6 address churn continues.

Confirmed affected models

CW9178I with Campus Gateway

Confirmed affected versions

R32.2: 32.2.3

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

The AP may unexpectedly reboot, temporarily disconnecting wireless clients and making its SSIDs unavailable while the AP and radios restart. Repeated occurrences can appear as intermittent wireless outages without a common feature or traffic pattern.

Conditions

This release addresses three identified causes that produce the same generic Wi-Fi radio error across the listed AP families. Because the exception is a broad failure category rather than one defect, no single configuration or client action triggers every occurrence, and a post-upgrade reboot with the same general report may have a different cause.

Resolution

The bundled Wi-Fi radio handling corrects three identified causes involving radio transmit processing and cleanup, preventing those variants from forcing AP recovery. Other unrelated radio faults can still produce the same generic exception, so repeated post-upgrade occurrences should be investigated separately with Meraki Support.

Workarounds

No confirmed configuration change avoids all variants because several independent radio faults share this report. If an AP repeatedly reboots, contact Meraki Support so the specific occurrence can be distinguished and the appropriate mitigation or software recommendation provided.

Confirmed affected models

MR36, MR44, MR56, MR57, CW9172I, CW9178I

Confirmed affected versions

• R31.1: 31.1.7.1, 31.1.8

• R32.1: 32.1.3 to 32.1.6

• R32.2: 32.2.2, 32.2.3

Back to release summary

Potential symptoms

Affected Wi-Fi 6E APs may unexpectedly reboot during client authentication.

Conditions

On MR57, a timing-dependent condition can occur when client authorization overlaps encryption-key installation. The condition is intermittent and does not occur with every client authentication.

Resolution

Firmware now completes encryption-key installation before authorizing the client, preventing the event-order race that caused the reboot.

Workarounds

No confirmed configuration workaround is available. Contact Meraki Support if repeated reboots occur.

Confirmed affected models

• MR57

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.4 to 32.1.6

• R32.2: 32.2.1 to 32.2.3

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

Affected Wi-Fi 6E APs may intermittently reboot, temporarily interrupting wireless service.

Conditions

On the listed APs, certain 6 GHz receive framing errors can leak buffers from the radio's receive-packet pool. Repeated occurrences can eventually exhaust the available packet buffers, forcing a radio recovery and AP reboot.

Resolution

Updated Wi-Fi radio handling flushes and releases receive-packet buffers after these framing errors, preventing the packet-buffer pool from being exhausted and avoiding the resulting reboot.

Workarounds

No confirmed configuration workaround is available. Contact Meraki Support if repeated reboots occur.

Confirmed affected models

• CW9162I, CW9163E, CW9164I, CW9166I, MR57

Confirmed affected versions

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

A CW9172I AP may unexpectedly reboot, disconnecting wireless clients and making its SSIDs unavailable while the AP and its Wi-Fi radios restart. Repeated occurrences can present as intermittent site-specific wireless outages.

Conditions

The issue can occur intermittently during normal operation when one of the AP's Wi-Fi radios processes a status indication from another Wi-Fi radio in the same AP. No customer configuration, client type, or traffic pattern has been confirmed as a reliable trigger.

Resolution

Updated Wi-Fi radio handling corrects communication between the AP's Wi-Fi radios so the affected status indication no longer causes an AP restart.

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 firmware recommendation provided.

Confirmed affected models

CW9172I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.2, 32.2.3

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

A Campus Gateway firmware upgrade may fail during the image-download step, leaving the gateway on its previous firmware. Dashboard Managed Firmware Upgrades reports The download_image command failed: Operation failed. The behavior is intermittent, so repeated attempts may fail before a later attempt succeeds.

Conditions

The issue occurs when a Campus Gateway receives the upgrade command but cannot establish the initial connection used to retrieve the firmware image. Configuration fetches can continue normally and local storage can remain available, so the failure is isolated to the image-transfer step. The issue is confirmed on 32.1.6; the exact broader affected-version and hardware-model scope is not fully established.

Resolution

The Campus Gateway image-download process now falls back to IPv4 when the initial connection cannot be established. Dashboard also retries the download step. Validation showed that remaining transient connection errors recovered on a subsequent retry without causing the entire upgrade to fail.

Workarounds

Retry the firmware upgrade because a subsequent image-download attempt may complete successfully. If repeated attempts continue to fail, contact Meraki Support before restarting gateway cluster members; restarts can reduce forwarding redundancy or interrupt service and should be planned for an appropriate maintenance window.

Confirmed affected models

Campus Gateway appliances; exact hardware-model scope is not fully established

Confirmed affected versions

• R32.1: 32.1.6

Back to Campus Gateway 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

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