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.

Resolution

Firmware now preserves the active association and encryption state when delayed cleanup removes the client's stale entry from the previous radio. Validation on CW9178I confirmed that only the previous-radio entry is removed after the timeout and client traffic continues.

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 administrator changes one LAN port in a port profile assigned to a CW9172H, other enabled LAN ports may power off even though their settings were not changed. Devices connected through those ports lose wired connectivity until the ports are powered back on.

Conditions

The issue occurs when a CW9172H has a Dashboard port profile assigned and an administrator changes a setting such as the SSID mapped to one port. Firmware incorrectly derives the desired power state from only the changed ports, so unchanged enabled ports may be treated as disabled; the same test does not reproduce on MR36H.

Resolution

Firmware now computes the complete desired enabled-port state from the updated port profile before applying power changes. Unchanged enabled ports therefore remain powered while only ports intentionally disabled by the new profile are turned off.

Workarounds

In Dashboard, use the AP's Ports tab to power-cycle any affected LAN ports after the profile change. This restores connectivity but causes a brief interruption for attached devices and must be repeated if another profile update triggers the issue.

Confirmed affected models

CW9172H

Confirmed affected versions

• R32.1: 32.1.7

• R32.2: 32.2.4

• R33.1: 33.1.2

Back to MR Access Point summary

Potential symptoms

Clients that were already selected for Band Steering may continue receiving BSS Transition Management requests after Band Steering is disabled. Those clients can continue to be encouraged away from 2.4 GHz even though the Dashboard configuration shows the feature as disabled.

Conditions

The issue requires Band Steering to be enabled on a dual-band SSID, an 802.11v-capable client to become an active steering candidate, and then Band Steering to be disabled while that candidate state remains. Existing candidate entries are not cleared by the configuration change, so periodic steering attempts continue; newly associated clients are not added after disablement.

Resolution

Firmware now clears active candidates for the affected SSID when Band Steering transitions from enabled to disabled and rechecks the current setting before each steering attempt. Candidate state for other SSIDs remains intact, and normal disconnect cleanup continues to operate.

Workarounds

Reboot the affected AP after disabling Band Steering to clear existing steering candidates. The reboot temporarily interrupts wireless service, so schedule it during a maintenance window; no further candidates are added while Band Steering remains disabled.

Confirmed affected models

CW9176I

Confirmed affected versions

• R32.1: 32.1.7

• R32.2: 32.2.4

Back to MR Access Point summary

Potential symptoms

A quiet device with a static IPv4 address, such as a printer, may intermittently stop responding to IPv4 traffic even though it remains associated and continues sending IPv6 control traffic. IPv4 reachability returns after the AP probes the device or after an administrator initiates traffic to it from the AP.

Conditions

The confirmed sequence involves a client using a static IPv4 address that sends little or no IPv4 traffic while frequent IPv6 Neighbor Discovery traffic keeps the client's general activity state fresh. The AP can then mark only the IPv4 address as unconfirmed without scheduling an IPv4 probe, causing proxy-ARP forwarding to omit requests for that client; follow-up reports without IPv6 require separate analysis and do not broaden this issue's confirmed trigger.

Resolution

Firmware now schedules IPv4 probing from the timestamp associated specifically with the client's IPv4 address instead of using a general timestamp that can be refreshed by IPv6 traffic. This keeps the IPv4 address state current independently of IPv6 activity and preserves IPv4 reachability.

Workarounds

No broadly reliable configuration workaround is confirmed. Initiating a ping to the client from the affected AP can restore reachability temporarily; contact Meraki Support if the behavior recurs, because disabling IPv6 or changing to DHCP did not resolve every reported occurrence.

Confirmed affected models

All APs

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R33.1: 33.1.1

Back to MR Access Point summary

Potential symptoms

A switch may learn a tunneled wireless client's MAC address on the AP uplink and start wired 802.1X or MAC Authentication Bypass for that address. On switch ports enforcing access policy, the failed wired authentication can place the AP uplink into a policy-violation state and interrupt service until the port is recovered.

Conditions

The AP is tunneling an SSID to Campus Gateway, the wired uplink enforces a port access policy, and client-sourced IPv6 multicast traffic remains queued while the client disconnects or roams. If tunnel state is removed before the queued frame is transmitted, the frame can leave the AP as ordinary VLAN traffic instead of remaining in the tunnel; the occurrence is timing-dependent and was reproduced by delaying queued uplink traffic.

Resolution

Firmware now verifies that the client is still in the tunneling state before transmitting queued traffic on the AP uplink. Frames that no longer have valid tunnel context are discarded instead of being emitted unencapsulated with the wireless client's source MAC.

Workarounds

Recover an affected switch port by bouncing it through the switch's normal administrative controls. This interrupts all service through that AP and does not prevent recurrence, so contact Meraki Support if repeated port-policy violations occur before upgrading.

Confirmed affected models

CW9178I

Confirmed affected versions

• R32.2: 32.2.3

Back to MR Access Point summary

Potential symptoms

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

Conditions

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

Resolution

Radio firmware configuration now disables the unsupported four-address learning behavior for MR operation. Validation with sustained traffic no longer reproduced the incorrect frame addressing or the resulting client connectivity loss.

Workarounds

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

Confirmed affected models

CW9172I, CW9176I

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.6

• R32.2: 32.2.3

Back to MR Access Point summary

Potential symptoms

Air Marshal may continue detecting a blocked SSID on 5 GHz but stop transmitting containment frames for it, while 2.4 GHz containment continues. The blocked BSSID remains visible to scanning data but is classified for alerting only until the AP is rebooted.

Conditions

The confirmed trigger occurs when the same blocked BSSID is first observed on a Dynamic Frequency Selection (DFS) channel, where containment transmission is prohibited, and later moves to a non-DFS channel where containment is allowed. The previous alert-only decision remains cached instead of being reevaluated against the BSSID's advertised primary channel; the behavior was reproduced across multiple containing APs.

Resolution

Firmware now distinguishes alert-only decisions caused by channel transmit restrictions, uses the AP's advertised primary channel, and reevaluates containment when that channel or the allowed-channel state changes. Policy-driven alert-only settings remain unchanged.

Workarounds

Rebooting the containing AP clears the stale classification and restores containment on the current non-DFS channel. The reboot interrupts wireless service and containment coverage during restart, so use it only as a temporary maintenance-window mitigation.

Confirmed affected models

All APs

Confirmed affected versions

• R32.1: 32.1.7

Back to MR Access Point summary

Potential symptoms

Adaptive Policy rules or bindings may not be installed, allowing traffic that the configured policy is intended to deny.

Conditions

Adaptive Policy is enabled and the valid policy configuration exceeds the previous 64 KB processing limit. This was observed with approximately 75 KB of policy data even though individual ACL and binding counts remained within supported limits.

Resolution

Firmware now accepts larger valid Adaptive Policy configurations, allowing supported ACL and binding counts to be applied when their combined data exceeds the previous limit.

Workarounds

Reduce the number or complexity of Adaptive Policy ACLs and bindings so the combined configuration remains below the previous size limit. Confirm that the reduced policy still provides the required access controls.

Confirmed affected models

All APs

Confirmed affected versions

• R31.1: 31.1.7.1

• R32.1: 32.1.4 to 32.1.7

• R32.2: 32.2.1 to 32.2.4

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.

Resolution

Updated radio firmware changes the resource-locking behavior so a blocked task can temporarily raise the lock holder's priority and complete its work. This prevents the prolonged starvation condition that triggers the radio watchdog.

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

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.

Resolution

Firmware now enforces matching 6 GHz group-management ciphers within an MBSS group only when beacon protection is enabled and the shared key requirement applies. Mixed security modes no longer trigger the watchdog check during ordinary 802.11ax operation.

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

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 to 33.1.3

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 to 33.1.3

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

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 to 33.1.3

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 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 to 33.1.3

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.

Resolution

Campus Gateway software now processes client deletion requests from older AP firmware even when those requests omit the newer anchoring indicators. The gateway therefore removes stale client and IP state instead of retaining it and later treating reused addresses as duplicates.

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

Potential symptoms

A wireless client may be unable to establish a working tunneled session after roaming between APs anchored to different Campus Gateways. The AP repeatedly requests an anchor response, but the affected gateway does not reply because it retains stale mobility state for the client.

Conditions

A tightly timed roam-out sequence causes a gateway to process an anchor request, a peer-gateway shadow-client request, and previous-client cleanup in overlapping order. The stale mobility-cache record can persist after the client has moved, and subsequent associations through that gateway fail until the record is cleared; the gateway hardware model scope is not fully established.

Resolution

Campus Gateway software now handles the overlapping roam and shadow-client events without replacing valid AP association context or retaining an unusable mobility-cache entry. Later anchor requests can therefore complete normally after the client roams.

Workarounds

Reboot the Campus Gateway that holds the stale client entry to clear the condition. This disrupts tunneled client service and should be scheduled in a maintenance window; contact Meraki Support to identify the affected gateway and coordinate recovery.

Confirmed affected models

Campus Gateway

Confirmed affected versions

• R32.1: 32.1.7

Back to Campus Gateway summary