Packet capture causing reboot

[BlakeRichardson]

Hi All

Overnight I upgraded my MR to MR 32.2.3 in an effort to resolve a network issue however I have noticed that whenever I run a packet capture it causes the AP to reboot, the affected devices are MR44.

So far I'm 3/3 with packets captures causing reboots. 

Is anyone else seeing this?

[Philip D'Ath]

I tested an MR36 on MR 32.2.3

If I do a packet capture on the wireless interface (no filters), it crashes.
If I do a packet capture on the wired interface (no filters), no issues.

Can you log a support ticket for this?  It's a bad one.  Include a link to this post.

This is my crash config:

This is my working config.

[Brash]

Oohh that's not good!
That said, I'm glad it's not wired captures that are broken.

[IanTonyBirchall]

Just out of curiosity, have you tried running the packet capture via API? Would be interesting to see if it is a front end issue. 
Alternatively id be asking the question how busy is the AP in question, an unfiltered packet capture could be quite resource intensive, are test completed inside or outside working hours? 

[Philip D'Ath]

I tested it on an AP with almost no connections.  Next to zero load.

[IanTonyBirchall]

i figured as much, but worth the ask. I tried on my Mr36 with 32.1.7 didnt have any issue. couple clients connected. 

[BlakeRichardson]

It gets worse, I downgraded to 32.1.7 and the issue remains. 

I spoke to support (Case ID 14328553) and apparently it's a known issue. 

[Pearl Pipe Fittings]

We have not experienced this issue on our MR44 access points running MR 32.2.3, but packet captures triggering AP reboots is definitely not expected behavior.

A few things worth checking:

• Review the Event Log for any crash or reboot-related entries immediately before the AP restarts.
• Confirm whether the reboot occurs with all packet capture types (wired, wireless, specific SSIDs, etc.) or only under certain conditions.
• Check if the affected MR44s have any hardware alerts or unusual resource utilization.
• If possible, test the same packet capture on another AP model running the same firmware to determine whether the issue is specific to the MR44 platform.
• Open a case with Meraki Support and provide the timestamps of the reboots so they can review backend crash logs.

Since you are 3/3 on reproducing the issue after upgrading to MR 32.2.3, it could be a firmware-related bug. It would be interesting to hear if others running MR44s on the same release can reproduce the behavior.

[Philip D'Ath]

Could you test doing a packet capture on the wireless interface, while pinging the access point's LAN interface, to confirm if it reboots, please?

[satzitg211]

If packet capture is causing the system to reboot, the issue is often related to the network adapter driver, packet capture driver, or an underlying hardware problem rather than the capture process itself. Reboots may occur when the capture tool places heavy load on the network stack, exposing driver instability or resource limitations. It is recommended to update network drivers, ensure the packet capture software is running the latest version, and review system event logs or crash dumps for errors that occur before the reboot. Testing with a different network adapter or reducing the capture load can also help determine the root cause of the problem.

[Philip D'Ath]

Could you let the AI know that this issue is happening on the access point itself, not a client, and see what it comes back with?

[Raphael_L]

Either these are bots or just people too lazy to come up with their solution. 

So annoying to see that many AI responses.

[CMR]

Yes, I miss the days where I could delete those posts, I reported both, so hopefully the AI slop will be gone soon...

[CMR]

I tried on a CW9166I running 32.2.3 and the wireless capture with the settings shown by @Philip D'Ath worked as expected.

[CMR]

It also does not crash an MR56 on the same network, but I have just noticed that the status LED on that unit has stopped working with the upgrade to 32.2.3, though if you choose to blink them, that still works...