Packet Capture stops after 20 seconds

[Xpyder]

Despite what it says on the capture page, when capturing packets it will stop after 20 seconds of not receiving any packets.  And only when outputting to the browser, capturing to pcap works as expected.

I submitted a bug report and apparently it's a feature so they won't fix it?

I came here because this seems weird for me; and actually directly interfered with troubleshooting an automated process with a several minute deviation in processing time (on the customer side) before it initiates a network connection, making it impossible to hit a 20 second window.

Is this something that's widely known or obvious that I should have expected?  Is it something that's desired or solving some underlying problem or vulnerability (or have some other reason for existing I'm not seeing)? 

Related to this forum post: https://community.meraki.com/t5/Network-Wide/Important-note-about-packet-captures/m-p/12410

[Xpyder]

I'm here mostly for a sanity check to make sure that not liking this behavior doesn't make me foolish or crazy, but also to take the temperature of the community on this feature.  To me it seems like something that needs to be changed, but I also want to make sure I'm not alone in it, and to gather enough feedback they might actually change this if it's a problem for more than just me

[BlakeRichardson]

@Xpyder  I have just tested an mine stops after 20 seconds after no data. At a guess this could be to reduce the load on their servers. 20 seconds almost seems like its been purposly set.

I would be interested to see what support say

[NolanHerring]

Mine does the same thing if no packets/frames are detected.

[GIdenJoe]

I found out it only happens when the output is on the screen.
When capturing to pcap file it usually remains on for the duration given.

I also have another issue with the packet capture tool on switches.

Since the packet capture is done from the dashboard, I suspect the capture is made after the frame has been processed by the ingress asic.  Since even with tagged or untagged VLAN assignments all captures from the dashboard have an 802.1Q tag assigned which does not always correspond to the incoming frame in a port.  So sometimes it's difficult to troubleshoot if a voice VLAN is getting the correct input from a phone or a server is tagging it's traffic as it should.