Potential symptoms

The Alternative Management Interface (AMI) may fail to renew its DHCP lease. When the lease expires, the AP can temporarily lose management connectivity over AMI or obtain a different address through a new DHCP discovery exchange.

Conditions

The issue occurs when AMI and the primary management interface use separate VLANs and DHCP servers. The AMI renewal request has the correct destination IP address but can use the Layer 2 destination learned for the primary interface, preventing the request from reaching the AMI DHCP server.

Resolution

The AP now maintains separate Layer 2 neighbor-resolution state for AMI DHCP traffic. Renewal requests are sent to the correct destination on the AMI VLAN, and replies are returned to the appropriate interface.

Workarounds

Using the same reachable DHCP server for the primary management interface and AMI avoids the incorrect destination selection. This may require a DHCP relay or network-design change, so contact Meraki Support before changing the management network.

Confirmed affected models

MR42, MR56, CW9162I

Confirmed affected versions

• R29: 29.7.1

• R30: 30.5, 30.6

Back to release summary

Potential symptoms

The AP's wired-interface statistics may show an increasing receive-length error counter. This can be mistaken for a cabling problem or packet loss, although the reproduced discovery frames were received successfully and were not dropped by this mechanism.

Conditions

The issue occurs on affected multi-gigabit AP Ethernet interfaces when a connected switch sends valid padded 802.3 LLC discovery or keepalive frames whose length field describes a payload shorter than the minimum Ethernet frame transmitted on the wire. It was observed with MR46, MR56, and MR57 APs connected to MS150 switches and with CW9176 APs connected to MS355 switches.

Resolution

The Ethernet receive handling now accepts these valid padded 802.3 frames without incorrectly incrementing the receive-length error counter.

Workarounds

No workaround is required for connectivity when only this counter is increasing, because the reproduced frames were received successfully. Connecting the AP to a switch that does not generate the affected frame format can prevent the misleading counter increase, but may not be operationally practical. Contact Meraki Support if the AP also shows confirmed packet loss or client-impacting symptoms.

Confirmed affected models

MR46, MR56, MR57, CW9176

Confirmed affected versions

• R31.1: 31.1.5, 31.1.7

Back to release summary

Potential symptoms

An upstream switch may report MAC flapping and client traffic may be disrupted because an AP sends traffic through both uplinks after failover recovery.

Conditions

MR57 with AP-side Link Aggregation Control Protocol (LACP) configured, connected to switch ports that are not configured for LACP, after an uplink fails and later reconnects.

Resolution

The AP now returns traffic to the primary uplink after it reconnects, preventing simultaneous forwarding across both links in this configuration.

Workarounds

Where the network topology permits, configure a supported end-to-end LACP connection. Otherwise, using a single AP uplink avoids MAC flapping after failover but removes uplink redundancy.

Confirmed affected models

MR57

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1

Back to release summary

Potential symptoms

APs may make unnecessary channel or transmit-power changes at approximately 30-minute intervals, causing avoidable client disruption.

Conditions

The radio-resource-management input can incorrectly treat an AP's own mesh-interface beacons as neighboring interference. The behavior is most visible when meshing is enabled.

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 meshing. Disabling meshing removes the self-beacon input that triggers the behavior, but it also prevents repeater operation and mesh failover.

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

An AP may continue sending beacons but stop answering probe requests and open-authentication frames on one or more radios, preventing clients from discovering or joining SSIDs.

Conditions

A queued probe response can be incorrectly filtered by radio hardware. Reports occurred after varying uptime, and a channel change or AP restart could temporarily restore service.

Resolution

Wi-Fi radio handling now clears the unexpected filter state for the AP's own BSSID. The correction is included across the affected Wi-Fi radio families; the release also retains corrected 5 GHz thresholds for MR46 and MR56.

Workarounds

A channel change or AP restart can temporarily restore probe and authentication responses. Either action interrupts client service and does not prevent recurrence.

Confirmed affected models

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

• Wi-Fi 6E: CW9162I, CW9163E, CW9164I, CW9166I, CW9166D1, MR57

• Wi-Fi 7: CW9171I, CW9172I, CW9172H, CW9174I, CW9176I, CW9178I, CW9179F

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 may show “Insufficient data” for average wireless latency on client and AP performance pages, or “N/A” for latency in Wireless Health when all APs in the network are affected. Client connectivity can continue normally, but administrators lose the latency telemetry used to evaluate wireless performance.

Conditions

The issue occurs on CW9176I or CW9178I APs when at least one active SSID uses GCMP-256 or SAE-EXT and the RF profile has 802.11be set to Off. The Wi-Fi radio does not apply latency capture during AP initialization in this configuration.

Resolution

Wi-Fi radio handling now applies latency capture independently of Wi-Fi 7-only controls, allowing telemetry collection whether the AP is operating with 802.11be enabled or disabled.

Workarounds

Setting 802.11be in the RF profile to any option other than Off, followed by an AP restart so the setting is reapplied, restores latency collection. This changes the intended Wi-Fi 7 configuration and interrupts clients during the restart, so contact Meraki Support before using it as a temporary workaround.

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 in Vusion Cloud after the AP loses and regains cloud connectivity. ESL service remains unavailable even though the AP itself can be online and otherwise serving wireless clients.

Conditions

The issue can occur after a connectivity interruption causes the ESL application to exit. The application container then remains in a created or stopped state and does not recover after connectivity returns; reports included APs that remained in this state for more than 24 hours.

Resolution

Application recovery now removes the stale container state and relaunches the ESL application after connectivity returns, allowing the AP to re-establish service with Vusion Cloud without an AP restart.

Workarounds

Restart the AP. The restart recovers the ESL application but temporarily interrupts AP and ESL service.

Confirmed affected models

CW9164I

Confirmed affected versions

• R31.1: 31.1.7, 31.1.7.1

• R32.1: 32.1.6

Back to release summary

Potential symptoms

Dashboard may report recurring “Config fetch error” alerts for MR44 APs, often at different times across APs in the same network. The alerts can clear without intervention after a later retry, and the AP may continue operating with its existing configuration.

Conditions

The behavior was observed after upgrading to MR 32 firmware when an MR44 temporarily could not read its secure hardware identity and attempted an alternate configuration-fetch method. A later secure retry could succeed, making the alert appear intermittent or recur approximately daily.

Resolution

The secure configuration-fetch process now handles the temporary identity-read failure and retry sequence correctly, preventing a transient unsuccessful attempt from producing the recurring alert when the AP can subsequently retrieve its configuration.

Workarounds

No action is generally required when the alert self-resolves and the AP remains online with a valid configuration. Contact Meraki Support if the alert remains active, configuration changes do not reach the AP, or the AP loses cloud connectivity.

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

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 authenticate successfully but receive an address from the wrong VLAN, or fail to obtain the expected network access, even though the RADIUS server returns the intended named VLAN.

Conditions

The issue occurs on SSIDs using RADIUS VLAN override when Dashboard has “Enable Named VLANs for use with RADIUS” enabled. The RADIUS server returns a VLAN name in the Tunnel-Private-Group-ID attribute, but the AP can ignore it when the SSID's VLAN setting is not itself set to Named VLAN.

Resolution

The AP now follows the Dashboard setting that enables named VLAN assignment from RADIUS and resolves the returned VLAN name to the configured VLAN ID, regardless of whether the SSID's default VLAN setting uses a numeric ID.

Workarounds

As a temporary workaround, configure RADIUS to return the numeric VLAN ID instead of a VLAN name. This requires matching RADIUS and Dashboard configuration and should be validated carefully to avoid changing client segmentation.

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

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

An MR57 AP may unexpectedly reboot, disconnecting clients and making its SSIDs unavailable while the AP and its Wi-Fi radios restart. Repeated occurrences can appear as intermittent wireless outages at an otherwise reachable site.

Conditions

The issue can occur while the AP is authenticating a wireless client if client traffic is authorized before the client's encryption key is fully installed. No specific SSID security mode, client type, or traffic threshold has been confirmed as a reliable customer-visible trigger.

Resolution

Wi-Fi radio handling now completes encryption-key installation before authorizing client traffic, preventing the invalid transmit state that caused the AP to restart.

Workarounds

No confirmed configuration workaround is available. The AP restarts automatically after an occurrence, but connected clients are interrupted while service recovers. Contact Meraki Support if an MR57 repeatedly reboots so the event can be matched to this issue.

Confirmed affected models

MR57

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.4 to 32.1.6

Back to release summary

Potential symptoms

An affected Wi-Fi 6E AP may unexpectedly reboot, disconnecting clients and making its SSIDs unavailable while the AP and its Wi-Fi radios restart. The issue was observed intermittently across multiple affected models rather than being limited to a single AP.

Conditions

The Wi-Fi radio can enter an invalid transmit state after an internal receive-buffer error during normal operation. No specific SSID configuration, client type, or traffic pattern has been confirmed as a reliable trigger.

Resolution

Wi-Fi radio handling now recovers from the affected receive-buffer state before it can progress to an error that restarts the AP.

Workarounds

No confirmed configuration workaround is available. The AP restarts automatically after an occurrence, but wireless service is interrupted during recovery. Contact Meraki Support if an affected AP repeatedly reboots so the event signature can be verified.

Confirmed affected models

CW9162I, CW9163E, CW9164I, CW9166I, CW9166D1, 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

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.

Confirmed affected models

CW9176I

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.3

• R33.1: 33.1.1

Potential 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.

Back to release 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

• R33.1: 33.1.1

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