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

Clients may fail 802.1X authentication and be deauthenticated because the AP stops transmitting EAP frames over the air.

Conditions

Wi-Fi 7 AP using 5 GHz with 40 MHz channel width and a minimum bitrate of 36 Mbps or higher. The issue is not known to occur with 20 MHz or 80 MHz channels or with minimum bitrates of 24 Mbps or lower.

Resolution

Updated firmware corrects transmission behavior at 40 MHz with higher minimum bitrates, allowing EAP frames to be transmitted normally.

Workarounds

Use a 5 GHz minimum bitrate of 24 Mbps or lower, or use a 20 MHz or 80 MHz channel width instead of 40 MHz. A 24 Mbps minimum bitrate is recommended because IEEE 802.11 defines it as the highest mandatory OFDM rate.

Confirmed affected models

• CW9176I, CW9178I

Confirmed affected versions

• R31.1: 31.1.7.1

• R32.1: 32.1.3 to 32.1.6

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

Some AP-generated ICMP traffic may carry SGT 0 instead of the configured SGT value, which can cause that traffic to be handled by an unexpected Adaptive Policy rule.

Conditions

Adaptive Policy is enabled. AP-generated connection-monitor pings and replies to pings sent to the AP management address can carry SGT 0 instead of the configured infrastructure SGT. Dashboard-initiated ping tests are not affected.

Resolution

AP-generated connection-monitor traffic and ICMP replies now retain and apply the configured infrastructure SGT.

Workarounds

No AP-side workaround is known. If the security policy permits, rules can temporarily account for SGT 0 on AP-generated ICMP traffic.

Confirmed affected models

• All APs

Confirmed affected versions

• R30: 30.7.1

• R31.1: 31.1.8

• R32.1: 32.1.3 to 32.1.6

• R32.2: 32.2.1

Back to release summary

Potential symptoms

The 2.4 GHz radio may operate at 16 dBm even when a higher transmit-power limit is configured.

Conditions

MR46E using an MA-ANT-3-B6 antenna in the FCC regulatory domain. Earlier firmware used a worst-case antenna gain instead of an antenna-specific power profile.

Resolution

Antenna-specific radio power profiles now account for MA-ANT-3-B6 gain, allowing MR46E to use the permitted transmit power.

Workarounds

No configuration workaround is known. Account for the lower 2.4 GHz transmit power in coverage planning until the AP is upgraded.

Confirmed affected models

• MR46E

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.4 to 32.1.6

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

Air Marshal may detect a blocked SSID without transmitting the broadcast deauthentication frames needed to contain it.

Conditions

The blocked SSID is on the same client-serving channel, wireless meshing is disabled, and containment must use a client-serving VAP. The issue is most visible on DFS channels because the scanning radio cannot provide fallback containment there.

Resolution

Containment transmission selection now retains an available client-serving interface when no mesh interface exists, allowing deauthentication frames to be transmitted with meshing disabled.

Workarounds

Enabling wireless meshing allows a mesh interface to transmit containment frames. Changing the mesh setting disrupts AP service and should be scheduled during non-critical hours. On non-DFS channels, the scanning radio may also provide containment.

Confirmed affected models

• All APs

Confirmed affected versions

• R31.1: 31.1.1 to 31.1.8

• R32.1: 32.1.1 to 32.1.6

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

EoGRE client traffic may stop forwarding because tunnel packets use a stale source address rather than the AP's current management address.

Conditions

An SSID uses an EoGRE concentrator and the AP management address changes, typically following a DHCP renewal or address change.

Resolution

AP management-address changes now refresh the EoGRE tunnel source address, preventing use of a stale encapsulation source address.

Workarounds

Using a stable management IP avoids the triggering address change. Rebooting the AP after its management IP changes temporarily refreshes the EoGRE tunnel source address, but interrupts wireless service and should be scheduled during non-critical hours.

Confirmed affected models

• All APs

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.1 to 32.1.6

• R32.2: 32.2.1

Back to release summary

Potential symptoms

RADIUS Access-Requests may contain a wildcard NAS IPv4 or IPv6 address, which can affect server policy matching, logging, or authentication handling.

Conditions

A RADIUS-enabled SSID is active while the AP management address changes and wireless authentication restarts during the brief interval in which the NAS address is unavailable.

Resolution

RADIUS-authenticated SSIDs now wait for a valid NAS address before starting authentication services, preventing unspecified addresses from being sent.

Workarounds

Use stable AP management addressing where practical. After changing an AP management address, confirm that RADIUS requests contain the expected NAS address before relying on address-based server policy.

Confirmed affected models

• All APs

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.1, 32.1.2, 32.1.4 to 32.1.6

• R32.2: 32.2.1

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 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, 32.2.2

Back to release summary

Potential symptoms

Epson printers using the UB-R05 wireless interface may fail association or authentication while the AP retransmits frames despite over-the-air acknowledgements.

Conditions

Wi-Fi 7 AP with an Epson UB-R05 802.11ac client, particularly on 5 GHz. For OFDM operation, IEEE 802.11 specifies a 16-microsecond Short Interframe Space (SIFS) before an acknowledgement response. The client begins transmitting acknowledgements before that interval, outside the specified timing.

Resolution

Older-generation Wi-Fi radio handling had already adjusted receive timing to accommodate similar client behavior reported by multiple enterprise equipment providers. Those adjustments were not applied by default to the newer Wi-Fi 7 chipset firmware, whose receive path remained disabled during much of SIFS to limit false packet detections. Updated Wi-Fi radio handling starts receive processing earlier and aligns receive-window timing across radio generations, allowing these early acknowledgements to be recognized.

Workarounds

No confirmed AP configuration workaround is available. Contact Meraki Support if affected clients cannot associate reliably.

Confirmed affected models

• Wi-Fi 7: All APs

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.1, 32.1.2, 32.1.4 to 32.1.6

• R32.2: 32.2.1

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

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

Wireless clients may be unable to discover services from other wireless clients because mDNS multicast traffic is dropped.

Conditions

A Wi-Fi 7 AP uses named VLAN assignment for clients that use multi-link operation. mDNS traffic can be compared against the wrong client VLAN and dropped.

Resolution

Firmware now associates mDNS traffic with the correct client data path and named VLAN, allowing multicast service discovery to be forwarded.

Workarounds

Use numeric VLAN IDs instead of named VLAN assignment on affected SSIDs. This requires an SSID and RADIUS configuration change.

Confirmed affected models

• Wi-Fi 7: All APs

Confirmed affected versions

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• All APs

Confirmed affected versions

• R32.1: 32.1.1 to 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

The 5 GHz radio may fail to start and the AP may repeatedly reboot.

Conditions

APs operating in Gabon. The Meraki cloud regulatory policy allows affected UNII-2c channels, including channel 104, but the AP's separate regulatory database omits them. When one of these channels is included in the AP's boot configuration, the wireless service rejects the channel during its standard startup checks and exits. The AP health monitor then reboots the AP because the service is no longer running, creating a reboot loop. If the AP first boots on a locally allowed channel and is later asked to use an omitted channel, it rejects the channel change but continues operating.

Resolution

The AP regulatory database now includes the same permitted UNII-2c channels as the Meraki cloud policy for Gabon. This keeps the two independent regulatory enforcement mechanisms aligned and allows wireless service startup to complete.

Workarounds

Use manual channel assignment to select a channel accepted by the AP's local regulatory database, or exclude the affected UNII-2c channels in the RF profile. If channel selection cannot otherwise be constrained, avoid dual-5 GHz mode by disabling the second 5 GHz radio. This also prevents the reboot loop but reduces radio capacity. Channel or radio changes disrupt wireless service and should be scheduled during non-critical hours.

Confirmed affected models

All APs

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.2 to 32.1.6

• R32.2: 32.2.1

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• CW9176I, CW9178I

Confirmed affected versions

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• CW9164I

Confirmed affected versions

• R31.1: 31.1.7, 31.1.7.1

• R32.1: 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• MR46, MR86

Confirmed affected versions

• R31.1: 31.1.7.1

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

The AP may reboot after a client joins the affected SSID. It can enter a reboot loop if clients reconnect before RADIUS accounting service is restored.

Conditions

An open SSID uses RADIUS accounting without RADIUS authentication, all configured accounting servers are unreachable, and a client associates. After the AP exhausts its accounting-request retries, the wireless service attempts to record the failure using authentication-server information that is not configured on an accounting-only SSID. This causes the wireless service to exit, after which the AP health monitor reboots the AP.

Resolution

Firmware now selects the configured accounting server when processing accounting failures and the configured authentication server when processing authentication failures. An unreachable accounting server therefore no longer causes the AP to reference missing authentication-server information or reboot.

Workarounds

Restore reachability to at least one RADIUS accounting server, or temporarily disable RADIUS accounting on the affected open SSID. Disabling accounting prevents accounting records from being sent. If the AP is already in a reboot loop, temporarily disable the affected SSID until an accounting server is responding; this disconnects clients and prevents use of that SSID.

Confirmed affected models

• All APs

Confirmed affected versions

• R30: 30.7

• R32.1: 32.1.6

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

An MR28 or MR78 may request PoE class 4 power (25.5 W) instead of its expected class 3 power budget.

Conditions

MR28 or MR78 connected to PoE infrastructure that reports or allocates power according to the requested class.

Resolution

MR28 and MR78 now request their correct 12 W power requirement, corresponding to PoE class 3.

Workarounds

No operational workaround is required. Until upgrade, ensure the PoE infrastructure has sufficient budget for the higher power reservation.

Confirmed affected models

• MR28, MR78

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.1, 32.1.2, 32.1.4 to 32.1.6

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• All APs

Confirmed affected versions

• R31.1: 31.1.6 to 31.1.8

• R32.1: 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• All APs

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.2, 32.2.3

Back to release summary

Potential symptoms

Affected APs may intermittently reboot, temporarily interrupting wireless service.

Conditions

CW9162I and CW9163E APs can experience this issue during normal operation. No narrower network configuration or client trigger is currently known.

Resolution

Updated Wi-Fi radio handling improves control-command processing so sustained radio activity does not trigger an AP recovery reboot.

Workarounds

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

Confirmed affected models

• CW9162I, CW9163E

Confirmed affected versions

• R31.1: 31.1.6 to 31.1.8

• R32.1: 32.1.3 to 32.1.6

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

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

Conditions

The Wi-Fi radio handling uses a buffer to hold pending control commands sent from the AP software to the radio. This buffer was too small for periods of sustained control activity and could fill before earlier commands completed, leaving the radio unable to accept another request and causing a recovery reboot.

Resolution

Updated Wi-Fi radio handling increases the capacity of the pending radio-control command buffer so bursts of control activity can be absorbed without forcing an AP recovery reboot.

Workarounds

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

Confirmed affected models

• CW9171I, CW9172I, CW9174I, CW9174E

Confirmed affected versions

• R31.1: 31.1.7.1, 31.1.8

• R32.1: 32.1.1 to 32.1.6

• R32.2: 32.2.1

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• MR57

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.4 to 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

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

Conditions

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

Resolution

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

Workarounds

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

Confirmed affected models

• CW9162I, CW9163E, CW9164I, CW9166I, MR57

Confirmed affected versions

• R32.1: 32.1.5, 32.1.6

• R32.2: 32.2.1 to 32.2.3

Back to release summary

Potential symptoms

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

Conditions

CW9162I and CW9163E APs can experience this issue during normal operation. No narrower network configuration or client trigger is currently known.

Resolution

Updated Wi-Fi radio handling improves low-level radio transaction handling to prevent the timeout that caused the reboot.

Workarounds

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

Confirmed affected models

• CW9162I, CW9163E

Confirmed affected versions

• R32.1: 32.1.6

• R32.2: 32.2.1, 32.2.2

Back to release summary

Potential symptoms

Affected Wi-Fi 7 APs may unexpectedly reboot while processing a client connection.

Conditions

On CW9176I with Wi-Fi 7 multi-link clients, a timing-dependent client-state condition can cause the wireless authentication service to fail.

Resolution

Firmware now validates and handles multi-link client state safely so the authentication service continues operating.

Workarounds

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

Confirmed affected models

• CW9176I

Confirmed affected versions

• R32.1: 32.1.4 to 32.1.6

• R32.2: 32.2.2

Back to release summary

Potential symptoms

AP wireless captures may contain duplicated Rx EAPOL, ARP, DHCP, or DNS traffic represented as additional 802.11 fragments. The more severe malformed/truncated-frame behavior reported on earlier firmware is not confirmed on r32.1.7.

Conditions

On CW9178I, this behavior can occur when proactive packet capture and a manual AP wireless capture run at the same time. It can occur with 20 MHz, 40 MHz, or 80 MHz channel widths.

Confirmed affected models

• CW9178I

Confirmed affected versions

• R31.1: 31.1.8

• R32.1: 32.1.6, 32.1.7

Potential workarounds

From Dashboard, navigate to Network-wide > Monitor > Intelligent Capture, open the Proactive PCAP Enablement tab, and remove the affected AP from the devices enabled for automatic capture. This prevents proactive and manual AP wireless captures from running at the same time, but automatic captures for client association and authentication failures will no longer be collected for that AP. Use an independent over-the-air monitor-mode capture when exact frame-level analysis is required.

Back to release summary

Potential symptoms

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

Conditions

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

Confirmed affected models

• MR28, MR46, MR56, MR76

• CW9162I, CW9164I, MR57

• CW9171I, CW9172I, CW9176I, CW9178I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.1 to 32.2.3

Potential workarounds

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

Back to release summary

Potential symptoms

A 6 GHz radio may operate below its configured static transmit power.

Conditions

Wi-Fi 6E or Wi-Fi 7 AP in the FCC regulatory domain on certain 6 GHz channels and channel widths. Reports include CW9166I and CW9179D1; the observed limit varies by channel and width.

Confirmed affected models

• CW9166I

• CW9179D1

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3

Potential workarounds

Try a different 6 GHz channel or channel width where coverage planning permits, because the observed limit varies by channel and width. Channel changes disrupt connected clients and may affect coverage or capacity. Contact Meraki Support if reduced power continues to affect coverage.

Back to release summary

Potential symptoms

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

Conditions

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

Confirmed affected models

• MR44

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.1 to 32.2.3

Potential workarounds

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

Back to release summary

Potential symptoms

An affected AP may unexpectedly reboot, temporarily interrupting wireless service.

Conditions

CW9176I can continue to experience unexpected reboots after upgrade to r32.1.7. Additional reports remain under investigation, and no configuration trigger is currently known.

Confirmed affected models

• CW9176I

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

• R32.2: 32.2.3

Potential workarounds

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

Back to release summary

Potential symptoms

Starting or running a wireless packet capture may disconnect clients and cause the AP to unexpectedly reboot.

Conditions

Affected Wi-Fi 6 and Wi-Fi 6E models while taking a packet capture. Reports often involved active traffic and 10 or more associated clients; both short and longer captures have reproduced the failure.

Confirmed affected models

• MR28, MR36, MR44, MR46, MR56, MR76, MR86

• CW9164I, CW9166I, MR57

Confirmed affected versions

• R32.1: 32.1.7

• R32.2: 32.2.3

• R33.1: 33.1.1

Potential workarounds

Avoid AP wireless packet captures on affected APs when possible. If a capture is required, contact Meraki Support before starting it.

Back to release summary

Potential symptoms

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

Conditions

MR57 and CW9166I can experience this issue during normal operation. No specific configuration, client type, or traffic trigger is currently known.

Confirmed affected models

• CW9166I, MR57

Confirmed affected versions

• R32.1: 32.1.6, 32.1.7

Potential workarounds

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

Back to release summary