MR 32.2.5 Release Notes

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

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 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. Wireless captures from each successful reproduction show a four-address Wireless Distribution System (WDS) frame transmitted by a wireless device and received by the AP even though the frame is not addressed to the AP. Processing that frame can cause the AP to send downstream QoS data frames with both distribution-system direction bits set. Meshing is enabled in the reported environments, and disabling meshing prevents recurrence there, but the available evidence does not establish meshing as a required trigger.

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

Disabling meshing prevented recurrence in the reported environments and can be used as a temporary mitigation, or an impacted client can be disconnected and reconnected 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

Clients using certificate-based local authentication may be rejected even when the Online Certificate Status Protocol (OCSP) responder reports that the client certificate is valid. The AP may log that it could not verify the OCSP response and terminate the EAP-TLS exchange.

Conditions

The SSID uses certificate-based local authentication with OCSP validation, and the OCSP response is signed directly by the client certificate issuer but does not embed that issuer certificate. The issue was reproduced on MR 32.2.4. A response signed by a separate delegated OCSP certificate still needs to include that signing certificate.

Resolution

Firmware now supplies the client certificate issuer as an additional candidate when verifying an OCSP response whose signer certificate is omitted. The response signature and full certificate chain are still validated against the configured trust store.

Workarounds

Configure the OCSP responder to include its signing certificate in the response. Some public OCSP providers do not offer this control; in that case, upgrade to MR 32.2.5 or a later compatible release.

Confirmed affected models

MR55, CW9166I, CW9178I

Confirmed affected versions

• R32.2: 32.2.4

Back to MR Access Point summary

Potential symptoms

A client using MAC-based authentication may receive an address on the default or native VLAN and remain there even though the RADIUS Access-Accept assigns a different VLAN. The client may therefore have connectivity on the wrong network segment or fail to reach resources on its intended VLAN.

Conditions

The issue is intermittent and timing-sensitive. It can occur when a MAC-authentication client associates or quickly reassociates while the RADIUS exchange is delayed or interrupted, and a DHCP server on the default VLAN supplies a lease before the RADIUS VLAN override is applied. The behavior was reproduced on the MR 32 branch and confirmed on MR56.

Resolution

Firmware now processes MAC-authentication state changes and releases buffered client traffic in a consistent sequence. This prevents the affected timing condition from leaving client traffic on the default VLAN.

Workarounds

Prevent the DHCP server on the default or native VLAN from leasing addresses to new wireless clients, for example by removing that DHCP scope or returning DHCP NACK responses. This can affect legitimate clients that use the default VLAN, so evaluate the change before deployment.

Confirmed affected models

MR56

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.4

Back to MR Access Point summary

Potential symptoms

Dashboard and the connected switch may report that an AP uplink has negotiated at 2.5 Gbps even though the AP Ethernet interface is specified for operation up to 1 Gbps. The link may pass traffic, but the unsupported negotiated mode creates misleading capacity information and an out-of-specification uplink state.

Conditions

The issue occurs when an AP uses automatic Ethernet negotiation and the connected multigigabit switch port advertises 2.5 Gbps. A missing speed-limit operation allows the AP to advertise and select 2.5 Gbps; when the connected switch advertises only speeds up to 1 Gbps, the AP negotiates at 1 Gbps as expected.

Resolution

Firmware now removes 2.5 Gbps from the AP Ethernet advertisement and restarts link negotiation after applying the platform speed limit. The AP therefore negotiates only supported Ethernet speeds.

Workarounds

Configure the connected switch port to advertise or operate at 1 Gbps before upgrading. Applying the setting briefly interrupts the AP uplink, but it does not reduce the AP's documented maximum Ethernet speed.

Confirmed affected models

MR78, MR28, GR12, GR62

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.4

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.

Resolution

Firmware now replays the current Ethernet link-up state after the AP reloads its forwarding configuration. This restores the wired transmit queues even when the original link event arrived during the reload, preventing the AP from remaining offline after an ungraceful power cycle.

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.

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

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 an internal 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

On the Dashboard page "Wireless > Air Marshal > Other SSIDs," an affected AP may report neighboring SSIDs with signal values around 253–255 dB. These physically impossible readings can make weak neighboring transmitters appear extremely strong and reduce the accuracy of Air Marshal visibility; they do not indicate an actual increase in RF signal strength.

Conditions

The issue is intermittent on the affected Wi-Fi 6 APs when the dedicated scanning radio decodes a beacon or probe response at or near receiver sensitivity. A slightly negative signal-to-noise ratio (SNR) may be represented as an unsigned value, causing values such as 253, 254, or 255 dB to be reported. The behavior was reproduced on MR56 and reported on several affected models that use the same scanning-radio implementation.

Resolution

The updated scanning-radio software validates low-end SNR measurements and incorporates corrected signal-processing behavior so a negative near-sensitivity value is recorded as a valid floor value instead of wrapping to 253–255 dB. Air Marshal therefore receives a bounded measurement for the affected frames.

Workarounds

No confirmed configuration workaround is available. Until the AP is upgraded, treat Air Marshal neighbor readings around 253–255 dB as invalid rather than as evidence of an unusually strong transmitter; contact Meraki Support if assistance is needed to distinguish affected entries. Upgrade to MR 32.2.5 or a later compatible release for the correction.

Confirmed affected models

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

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.6

• R32.2: 32.2.4

Back to MR Access Point summary

Potential symptoms

An affected Wi-Fi 7 AP may experience an unexpected 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

An AP may experience an unexpected 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.

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

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 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 an AP health watchdog that monitors wireless interface startup restarts the AP; other regulatory domains without outdoor 6 GHz authorization may also be affected but are not confirmed.

Resolution

Firmware now preserves the CW9163E default that leaves the 6 GHz radio disabled when site survey mode starts unless that radio is explicitly enabled with a valid channel. The AP no longer attempts to start the radio without an authorized Automated Frequency Coordination channel and therefore does not enter the reboot cycle.

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.

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

Back to MR Access Point summary

Potential symptoms

An affected AP may experience an unexpected 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 exact customer configuration or traffic sequence that produces the identified radio watchdog event is unknown, so there is no reliable action an administrator can use to predict or reproduce it. The event has been observed during normal operation on the listed models and firmware.

Resolution

MR 32.2.5 incorporates updated radio firmware for both affected radio families. The update corrects the transmit-flow cleanup condition associated with the identified radio watchdog event, preventing that condition from forcing an AP restart.

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.

Confirmed affected models

MR44, MR46E, MR57, MR86, CW9166D1, CW9166I

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

Back to MR Access Point summary

Potential symptoms

An affected AP may experience an unexpected 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.

Resolution

MR 32.2.5 includes updated scanning-radio firmware that corrects a power-management failure during radio startup. This prevents the associated radio assertion from forcing the AP to restart.

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.

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

Back to MR Access Point summary

Potential symptoms

An affected AP may experience an unexpected 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 now preserves consistent packet state when traffic is processed concurrently, preventing the affected condition from triggering an unexpected AP reboot.

Workarounds

No confirmed configuration workaround is available on affected firmware. Upgrade to MR 32.2.5, MR 33.1.2, or a later compatible release; 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

Affected Wi-Fi 6E APs may experience an unexpected reboot, temporarily interrupting wireless service.

Conditions

MR57 and CW9166I can experience this issue during normal operation. Available engineering evidence indicates that the issue is very rare. No specific configuration, client type, or traffic trigger is currently known.

Resolution

The radio firmware update corrects the affected transmit-processing condition that can trigger this fault. The AP therefore remains operational instead of restarting for this condition.

Workarounds

No confirmed configuration workaround is available on affected firmware. Upgrade to MR 32.2.5 or a later compatible release; contact Meraki Support if repeated reboots continue after upgrading.

Confirmed affected models

CW9166I, MR57

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

Back to MR Access Point summary

Potential symptoms

CW9176I APs may experience an unexpected reboot after PoE allocation changes, disconnecting associated clients and temporarily making wireless service unavailable while the AP restarts.

Conditions

The issue occurs intermittently when negotiated PoE allocation changes repeatedly move a CW9176I between reduced-power operating states. A wireless-subsystem reload during this sequence can fail to fully restore radio monitoring, leading the watchdog to restart the AP.

Resolution

Firmware now defers the post-reinitialization PoE check until link-layer power negotiation has settled. This prevents a transient power reading from repeatedly changing the AP’s reduced-power state and reloading the wireless subsystem, avoiding the condition that triggers the reboot.

Workarounds

No confirmed AP configuration workaround is available on affected firmware. Verify that the upstream switchport provides stable, sufficient PoE, then upgrade to MR 32.2.5 or a later compatible release; contact Meraki Support if power allocation continues to change or reboots persist.

Confirmed affected models

CW9176I

Confirmed affected versions

• R32.2: 32.2.4

• R33.1: 33.1.1 to 33.1.3

Back to MR Access Point summary

Potential symptoms

A CW9178I may experience an unexpected reboot while upgrading to MR 32.2.4, remain offline for an extended period, and fail to complete the upgrade or return to the previous firmware.

Conditions

The issue is confirmed on newly deployed CW9178I APs that were first staged from an earlier MR 31 release to MR 31.1.8 and then upgraded to MR 32.2.4. The failure is associated with the AP storage service during the upgrade sequence.

Resolution

MR 32.2.5 incorporates an updated AP service associated with the reported reboot and improves firmware-upgrade recovery. The upgrade process now preserves the boot-state information needed to confirm the current firmware image and safely rolls back if that information is missing, addressing the documented failure to complete the upgrade.

Workarounds

Do not repeatedly retry the affected upgrade sequence. Contact Meraki Support for a currently recommended alternate upgrade path or firmware release.

Confirmed affected models

CW9178I

Confirmed affected versions

• R31.1: 31.1.8

• R32.2: 32.2.4

Back to MR Access Point summary

Potential symptoms

CW9164I and CW9166I APs may stop responding to SNMPv3 requests even though the SNMP service remains running. Monitoring systems receive timeouts, and local SNMP queries on the affected AP also fail.

Conditions

The issue has been observed intermittently on a subset of APs after sustained SNMP polling. Requests accumulate without being processed, but the exact polling sequence and time to onset have not been reproduced consistently.

Confirmed affected models

CW9164I, CW9166I

Confirmed affected versions

• R32.2: 32.2.1 to 32.2.5

• R33.1: 33.1.1 to 33.1.4

Potential workarounds

Rebooting an affected AP temporarily restores SNMP responses, but the issue may recur and the reboot interrupts wireless service. Contact Meraki Support to coordinate recovery and collect diagnostic information before rebooting when operationally practical.

Back to MR Access Point summary

Potential symptoms

Clients connected on 5 GHz may experience intermittent latency spikes, packet loss, and substantially reduced throughput while remaining associated. Webpages and other network applications may load slowly or fail to complete. The degradation can affect a subset of APs, persist after client counts fall, and temporarily clear after an AP restart or channel change.

Conditions

The issue affects a subset of APs on the listed firmware. Reports include high-density deployments and APs serving only a few clients, including periods without high channel utilization or obvious RF interference. Current engineering analysis focuses on radio transmission failures during single-user transmit beamforming, but the exact triggering sequence is not fully characterized. Candidate radio-software corrections are undergoing validation; no released fix is confirmed.

Confirmed affected models

MR44, MR46, MR56, CW9164I, CW9166I

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

• R33.1: 33.1.3

Potential workarounds

Restarting the AP or changing its channel may temporarily restore performance; either action disconnects clients, and degradation may recur. Downgrading to a compatible MR 30 or MR 31 release has restored service in reported deployments. Recent engineering comparisons use MR 32.1.7 as an earlier baseline, but recovery on that release is not established for every affected deployment. Contact Meraki Support to select a compatible previously working release, confirm recovery, and obtain current mitigation guidance. Firmware changes interrupt wireless service. No configuration-only workaround is confirmed.

Back to MR Access Point summary

Potential symptoms

Wireless clients connected to a CW9178I may lose gateway connectivity for several seconds when one member of the AP's LACP uplink is disconnected, even though the other member remains connected. Testing includes approximately 4–5 seconds of interruption and up to six consecutive unanswered gateway pings before forwarding resumes.

Conditions

The AP's two Ethernet interfaces and upstream switch ports are configured as an LACP bundle. The issue occurs intermittently when one physical member is disconnected and link-loss notification reaches the AP's uplink handling later than the physical-link event. The surviving member remains available, but traffic does not immediately fail over to it.

Confirmed affected models

CW9178I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.1 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available on MR 32.2.5. Schedule LACP member maintenance during a maintenance window and allow for a brief client interruption. Contact Meraki Support for current failover guidance if traffic does not recover through the surviving member.

Back to MR Access Point summary

Potential symptoms

APs may continue to broadcast Client Balancing load updates every five minutes even when Client Balancing is disabled. Packet captures may show UDP port 61111 broadcasts; these messages report load and channel-utilization information and do not by themselves initiate a client-steering action.

Conditions

The behavior is confirmed on CW9162I and CW9176D1 APs running the listed firmware. A periodic channel-utilization reporting path can publish a load update without checking whether Client Balancing is enabled.

Confirmed affected models

CW9162I, CW9176D1

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. The load updates do not themselves steer clients. Contact Meraki Support if the broadcasts conflict with monitoring or network policy.

Back to MR Access Point summary

Potential symptoms

A client using MAC authentication may stop forwarding traffic several minutes after it roams between radios on the same AP, even though the client remains associated and has completed authentication.

Conditions

The issue is confirmed on a dual-band MAC-authentication SSID when a client reassociates between the 5 GHz and 2.4 GHz radios on the same AP. Delayed cleanup of the previous radio association can clear the authorization state used by the active association approximately five minutes after the roam.

Confirmed affected models

CW9178I; exact broader model scope is not fully established

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Downgrade the affected AP to a compatible MR 31 release. A firmware change restarts the AP and interrupts wireless service, so schedule it during a maintenance window and contact Meraki Support for deployment-specific guidance.

Back to MR Access Point summary

Potential symptoms

Clients on RadSec-enabled SSIDs may fail to authenticate even though the AP has a valid certificate and its RadSec service appears to be running. The AP can receive local authentication requests without sending corresponding RadSec traffic over the wired uplink, leaving client connection attempts unanswered.

Conditions

The issue is reported intermittently on CW9166I APs using RadSec (RADIUS over TLS). The exact trigger and time to onset are not established. Server response behavior and RADIUS accounting support are also being checked, so the available evidence does not establish one cause for every reported authentication timeout.

Confirmed affected models

CW9166I

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Rebooting an affected AP has restored authentication service, but the reboot disconnects wireless clients and is not a permanent correction. Contact Meraki Support to coordinate recovery and collect diagnostic information before rebooting when operationally practical. No confirmed configuration workaround is documented.

Back to MR Access Point summary

Potential symptoms

The Vusion electronic shelf-label (ESL) application on MR46 APs may repeatedly restart or lose its cloud connection, temporarily preventing label updates. Labels can retain stale information or display no pricing during an interruption. Reported recovery intervals are approximately one to two minutes; normal Wi-Fi service and AP cloud connectivity can remain available.

Conditions

Reports involve the Vusion BLE ESL application version 2.7.3.0. Events include application configuration changes, cloud-session disconnects, and failures to reach an authentication endpoint. The initiating cause remains under investigation; a companion log-recording process can also fail during application teardown, but that does not establish it as the cause of the ESL interruption.

Confirmed affected models

MR46

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

The application may recover automatically once cloud communication is restored. Contact Meraki Support and the ESL provider to check application status and required cloud connectivity when interruptions persist. No confirmed firmware or configuration workaround is available; reverting to an older ESL application has not provided reliable recovery in the reported deployment.

Back to MR Access Point summary

Potential symptoms

Speaker groups may stop delivering audio to member speakers when their stream changes from unicast to multicast. In the reported Sonos setup, two speakers work, but adding a third causes audio to remain audible only on the group coordinator.

Conditions

Wi-Fi Personal Network (WPN) is enabled on the SSID, and the speakers belong to the same WPN group. The failure is associated with multicast distribution between group members. The exact forwarding failure remains under investigation; toggling multicast-to-unicast conversion did not restore the reported stream.

Confirmed affected models

Exact AP model scope is not fully established

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3 to 32.2.5

Potential workarounds

Disabling the Dashboard control "Wi-Fi Personal Network (WPN)" on the affected SSID has restored streaming. This removes WPN's per-user segmentation, so assess the isolation requirements before making the change and coordinate it with Meraki Support. Changes to the SSID can disrupt connected clients.

See Wi-Fi Personal Network documentation for the isolation behavior to assess before disabling WPN.

Back to MR Access Point summary

Potential symptoms

A 6 GHz radio may report transmit power below the configured static value, potentially changing the intended coverage level. The observed cap varies with the operating channel and channel width.

Conditions

Reports involve CW9166I and CW9176D1 APs in the FCC regulatory domain. Engineering is validating the delivered power-limit tables and conducted versus radiated measurements. Recent CW9176 test results do not support a simple increase to the current limits; applicability of those results to the CW9166 reports remains under review.

Confirmed affected models

CW9166I, CW9176D1

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support to verify the AP model, regulatory domain, operating channel, channel width, and reported power before changing the RF design. Any coordinated channel or width change can interrupt clients and alter coverage or capacity.

Back to MR Access Point summary

Potential symptoms

A teleworker VPN SSID may stop broadcasting after the primary concentrator becomes unavailable, preventing clients from connecting even though the configured secondary concentrator is reachable.

Conditions

The issue is intermittent and requires a teleworker VPN SSID with primary and secondary concentrators, active DHCP monitoring, and no associated clients or ordinary tunnel traffic. It is more readily reproduced when the AP restarts while only the secondary concentrator is available; the AP may continue reachability checks without completing the secure tunnel.

Confirmed affected models

Exact model scope is not fully established

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

• R33.1: 33.1.3

Potential workarounds

Restore reachability to the primary concentrator. If that is not possible, contact Meraki Support before changing the primary and secondary concentrator configuration; restarting the AP can reproduce the condition and is not a reliable recovery.

Back to MR Access Point summary

Potential symptoms

Dashboard may show high 6 GHz non-802.11 utilization on CW9166I APs even when an external spectrum check finds no corresponding non-Wi-Fi interferer. Reports are most apparent during busy periods in dense deployments, and the measurement can give administrators a misleading indication of external interference.

Conditions

Reports involve dense 6 GHz deployments in the UK/ETSI regulatory domain. Sensitive radio energy-detection settings can count distant Wi-Fi transmissions as non-802.11 energy when their preambles cannot be decoded. The reporting behavior and suitable permanent threshold settings remain under validation.

Confirmed affected models

CW9166I

Confirmed affected versions

• R31.1: 31.1.8

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Contact Meraki Support to assess a temporary radio energy-detection adjustment. Limited field testing on MR 32.2.4 reduced the reported non-802.11 utilization, but the adjustment is lost after an AP reboot and firmware integration still requires validation. Corroborate the reported utilization with spectrum measurements before treating it as evidence of a non-Wi-Fi interferer.

Back to MR Access Point summary

Potential symptoms

Clients using Local Auth with Opportunistic Key Caching (OKC) may be deauthenticated after approximately 2 hours and 59 minutes and then need to authenticate again. This interrupts client connectivity more frequently than the 12-hour session behavior reported with Fast Transition.

Conditions

The issue is reported on a Local Auth SSID where the authentication response sets a Session-Timeout of 10,740 seconds. The AP expires the client's cached authentication state at that interval. The exact AP model scope is not yet established.

Confirmed affected models

Exact AP model scope is not fully established

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

Enabling the Dashboard "802.11r" control (Fast Transition) on the affected SSID has increased the reported session period to 12 hours. Validate client compatibility before enabling it and coordinate the SSID change with Meraki Support; configuration changes can interrupt service, and session expiry is delayed rather than eliminated.

Back to MR Access Point summary

Potential symptoms

MR44, CW9162I, and CW9172I APs may experience an unexpected reboot, disconnecting associated clients and temporarily making wireless service unavailable while the AP restarts.

Conditions

The issue occurs intermittently during client reassociation activity involving Protected Management Frames (PMF). Available engineering evidence associates it with incomplete cleanup of a previous protected client association during rapid reassociation, but the exact traffic sequence needed to trigger it is not fully characterized.

Confirmed affected models

MR44, CW9162I, CW9172I

Confirmed affected versions

• R32.1: 32.1.5 to 32.1.7

• R32.2: 32.2.1 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. The AP recovers by rebooting, but associated clients are disconnected during the restart. Contact Meraki Support if repeated reboots occur.

Back to MR Access Point summary

Potential symptoms

CW9172I APs may experience an unexpected reboot, temporarily interrupting wireless connectivity for associated clients.

Conditions

A radio-firmware failure is associated with these reboots. Similar diagnostic signatures can represent different failure paths, and no specific customer configuration or traffic sequence is confirmed as a trigger.

Confirmed affected models

CW9172I

Confirmed affected versions

• R32.2: 32.2.4 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support if reboots recur so the diagnostic signature can be confirmed and appropriate firmware guidance provided.

Back to MR Access Point summary

Potential symptoms

MR44, CW9172I, and CW9176I APs may experience an unexpected reboot, disconnecting associated clients and temporarily interrupting wireless service while the AP restarts.

Conditions

Available engineering evidence includes more than one timer-related failure path. Some reports involve cleanup of Protected Management Frames (PMF) security-query timers, while other reports have a different timer-failure signature. A specific configuration or traffic trigger is not confirmed, and matching reboot reports require Support correlation.

Confirmed affected models

MR44, CW9172I, CW9176I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3 to 32.2.5

Potential workarounds

No confirmed configuration workaround is available. Contact Meraki Support if repeated reboots occur so the failure path can be identified and an appropriate software recommendation provided. Each reboot interrupts service to associated clients.

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

Potential symptoms

Applications may establish a TCP connection but then stall or fail when a downstream response is larger than 1412 bytes. For example, a TLS handshake can stop after the server sends its initial response because the Campus Gateway drops the packet before it reaches the AP and wireless client.

Conditions

The issue occurs on MR 32.2.4 when Campus Gateway uses the default hybrid VXLAN mode: management traffic is encrypted while data traffic is unencrypted. The gateway incorrectly applies a 1412-byte tunnel maximum transmission unit (MTU) to unencrypted downstream data, so packets from 1413 through 1450 bytes are dropped. Comparative validation across disabled, management-only, and management-plus-data encryption modes isolated the defect to the management-only hybrid mode.

Resolution

Campus Gateway software now reports and applies the correct 1450-byte data-path MTU when management traffic is encrypted and data traffic is unencrypted. Downstream packets within the supported 1450-byte size are forwarded instead of being dropped.

Workarounds

Downgrade to MR 32.2.3, or enable the Dashboard control "Data traffic encryption enabled on networks" for the affected AP networks. As another temporary option, clamp the upstream client-gateway MTU to 1412 bytes if the rest of the path supports that value. A downgrade or encryption change reloads tunnel state and should be scheduled in a maintenance window; MTU clamping reduces the usable packet size.

Confirmed affected models

Campus Gateway

Confirmed affected versions

• R32.2: 32.2.4

Back to Campus Gateway summary

Potential symptoms

Wireless clients may lose connectivity for approximately 6–8 seconds while APs move their tunnels to the standby Campus Gateway. Connectivity recovers without administrator intervention after failover completes.

Conditions

The behavior has been reproduced when the redundancy ports of a Campus Gateway high-availability pair are directly connected and power is removed abruptly from the active chassis. The standby gateway detects redundancy-link loss quickly, but its separate peer connection can take longer to time out, allowing AP-side Bidirectional Forwarding Detection (BFD) to initiate failover before the standby gateway declares its peer unavailable.

Resolution

MR 32.2.5 includes corrected Campus Gateway high-availability peer-down handling for the delayed failure-notification path described here. The correction addresses the condition that left APs relying on their own failure-detection timeout before switching to the surviving chassis. The available engineering evidence does not establish a guaranteed post-fix failover duration.

Workarounds

No confirmed configuration workaround shortens this failover path. Connectivity recovers automatically after the standby gateway takes over; contact Meraki Support if disruption lasts longer or failover does not complete.

Confirmed affected models

Campus Gateway

Confirmed affected versions

• R32.2: 32.2.3

Back to Campus Gateway summary

Potential symptoms

A Campus Gateway may experience an unexpected reboot after its wireless control process stops, interrupting tunneled client service while the gateway or high-availability peer recovers. Multicast DNS (mDNS) discovery traffic is present immediately before the affected processing path.

Conditions

The issue is associated with mDNS filtering at the Campus Gateway and IPv6 Neighbor Discovery Protocol traffic. The available evidence confirms the behavior on MR 32.1.6 but does not establish a complete gateway hardware scope or a precise packet sequence that administrators can use to predict recurrence.

Resolution

Campus Gateway software now handles the affected IPv6 neighbor-discovery input during mDNS gateway filtering without terminating the wireless control process. This prevents the process fault from causing an unexpected gateway reboot.

Workarounds

No confirmed customer configuration workaround is available. Contact Meraki Support if a Campus Gateway experiences an unexpected reboot while mDNS gateway filtering is in use so the event can be correlated and recovery guidance provided.

Confirmed affected models

Campus Gateway

Confirmed affected versions

• R32.1: 32.1.6

Back to Campus Gateway summary