[tcpdump-workers] [tcpdump] New feature to limit capture file size (#464)

Guy Harris guy at alum.mit.edu
Wed Jun 10 22:53:08 EDT 2015

On Jun 10, 2015, at 4:35 AM, Darren Reed <darrenr at netbsd.org> wrote:

> On 10/06/2015 5:42 AM, Michael Richardson wrote:
>> re: https://github.com/the-tcpdump-group/tcpdump/pull/464 Guy writes:
>>> We have the -C option, giving a file size in megabytes (real megabytes, i.e. 1,000,000 bytes, not 1,048,576 bytes); once the file gets that big, tcpdump switches to a new file. This adds another file size option, with a different syntax for the size option, and with tcpdump stopping rather than rotating files when it reaches that size. We also have the -G option, to rotate files based on time rather than size. We might want to consider cleaning up these options a bit, so that we can specify "stop" vs. "rotate" and "file size" rather than "capture time" independently. 
>> thoughts? I'm happy to accept the patch once sane, and then clean it up as Guy suggests.
> Maybe it is time to work out how this should interact now...
> Why is there even a need to have -G and -C?

"Why was there a need to have -G and -C?"  Not clear.

"Why *is* there a need to have -G and -C?"  As Wesley Shields indicated, the answer is "for backwards compatibility".

I.e., something cleaner probably *should* have been done, but that's water under the bridge; we could do something arguably cleaner, along the lines of Wireshark's -a and -b flags, but, if we do that, we still need to keep -G and -C around for the benefit of older scripts.

I think the cleaner flags should:

	1) allow checks for file size and capture time (and packet count?);

	2) allow either stopping the capture, switching capture files (with no upper bound on the number of capture files), or rotating capture files (with an upper bound on the number of capture files);

with 1) and 2) being orthogonal.

I don't know whether there's a need to, in 1), allow *multiple* criteria, with, presumably the capture stopping/switching/rotating when any of the criteria are met.

More information about the tcpdump-workers mailing list