New feature to limit capture file size

[stevekay]

I have cancelled an earlier similar pull request I made. This pull request incorporates the suggestions concerning ambiguous else, int overflow and trailing whitespace.

$ sudo ./tcpdump -w /tmp/foo -i eth0 --limit-file-size=2k
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
$ ls -lh /tmp/foo
-rw-rw-r--. 1 steve steve 2.2K Jun  7 14:39 /tmp/foo
$ man -l tcpdump.1.in | grep -C 5 limit-file-size

       --immediate-mode
              Capture  in "immediate mode".  In this mode, packets are delivered to tcpdump as soon     as they arrive, rather than being buffered for efficiency.  This is the default when printing packets rather than saving packets to
              a ``savefile'' if the packets are being printed to a terminal rather than to a file or pipe.

       --limit-file-size=max_size
              Once the capture file exceeds max_size do not capture any further packets.  Default     format is bytes, but suffixes k, m and g can be used to denote kilobytes, megabytes and gigabytes respectively.

       -j tstamp_type
       --time-stamp-type=tstamp_type
              Set the time stamp type for the capture to tstamp_type.  The names to use for the time stamp types are given in pcap-tstamp(@MAN_MISC_INFO@); not all the types listed there will necessarily  be  valid  for  any  given
$

[guyharris]

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.

[stevekay]

Indeed. Cleaning up / consolidating options would be good. Bit of a struggle keeping backward compatibility, mind.

Note this pull request is in response to issue #97 which itself was carried over from SourceForge issue http://webcache.googleusercontent.com/search?q=cache:9fbyrQQJZnMJ:sourceforge.net/p/tcpdump/bugs/93/+&cd=2&hl=en&ct=clnk&gl=uk (created 31-Jan-2008, quite a vintage)

[guyharris]

Fortunately, --limit-file-size isn't yet in tcpdump, so we can make its behavior whatever we want it to be.

How about making its size default to megabytes (as in "1,000,000 bytes"), just as it is for -C, and have it support "k", "m", and "g", meaning kilobytes (as in "1,000 bytes"), megabytes, and gigabytes (as in "1,000,000,000 bytes"), with "ki" meaning "kibibytes" (as in "1,024 bytes"), "mi" meaning "mibibytes" (as in "1,048,576 bytes"), and "gi" meaning "gibibytes" (as in "1,073,741,824 bytes)?

Then we can add those suffixes to -C as well.

[stevekay]

Good points. Try this for size then, pun intended. https://github.com/stevekay/tcpdump/commit/e7ed12bc027628de15e2960bf45dd091f3847d6f

[guyharris]

Slightly easier way to parse numerical arguments possibly followed by a suffix:

• Use strtol() or strtoul(), with a base of 10. It'll provide a pointer to the first character it didn't parse as part of a number, via the second argument.
• If that's the beginning of the string, the string isn't a valid file size; treat that as an error.
• Otherwise, compare the remaining part of the string with "", "k", "m", "g", "ki", "mi", and "gi". If it matches "", multiply by 1,000,000; if it matches one of the other suffixes, multiply by the appropriate amount; otherwise, the string isn't a valid file size.

See, for example, the way we handle the -i and -s options.

[stevekay]

OK, now revised as suggested.

[guyharris]

Our style puts spaces around assignment operators and after commas that separate arguments, so do l = strtol(x, &e, 10);.

Also, right after you do that, fail if x == e, unless you want the user to be able to just specify, for example, "kb" as an argument, with no number. (That's the "if that's the beginning of the string, the string isn't a valid file size" clause in my earlier comment.)

Also, I've just added an ascii_strcasecmp() routine, which does a case-insensitive comparison of ASCII strings, without trying to do any case-mapping of non-ASCII characters. We want "10KIB" to work as well in Turkey as it does elsewhere (in Turkish, there are separate dotted and non-dotted "i"s, so the upper-case version of "kib" would have a dotted capital I as the second character). (Wireshark had an issue with this several years ago, so it's been burned into my brain. :-))

[stevekay]

Our style puts spaces around assignment operators and after commas that separate arguments...

Yes, had missed a few instances, now fixed.

Also, right after you do that, fail if x == e, unless you want the user to be able to just specify, for example, "kb" as an argument, with no number...

Can add such a test if you want it to improve readability, but functionally it is not required. That is caught by the if (l < 1).

$ sudo ./tcpdump -w /tmp/foo --limit-file-size 0
tcpdump: invalid file size 0
$ sudo ./tcpdump -w /tmp/foo --limit-file-size k
tcpdump: invalid file size k
$ sudo ./tcpdump -w /tmp/foo --limit-file-size ki
tcpdump: invalid file size ki
$ sudo ./tcpdump -w /tmp/foo --limit-file-size 0k
tcpdump: invalid file size 0k
$ sudo ./tcpdump -w /tmp/foo --limit-file-size 0ki
tcpdump: invalid file size 0ki
$

Also, I've just added an ascii_strcasecmp()...

Great, now revised to make use of that.

[faunris]

@stevekay
@guyharris
Hi, what about this PR?

[sindhudhatri]

Hi,
We also are checking a similar kind of usecase with tcpdump. So can you please confirm if this limit of file size option is supported or not. If yes, in which version of tcpdump.
On our machine, we have:

tcpdump --version

tcpdump version 4.1.1
libpcap version 0.9.8

Thanks,
Sindhu

[mcr]

sindhudhatri <[email protected]> wrote: We also are checking a similar kind of usecase with tcpdump. So can you please confirm if this limit of file size option is supported or not. If yes, in which version of tcpdump. On our machine, we have: tcpdump --version tcpdump version 4.1.1 libpcap version 0.9.8 We just released 4.9. The 4.1 version is a decade old.

…

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [

[sindhudhatri]

Hi,
Thanks for the response. So you mean with the latest version of 4.9 only we have the functionality of stopping the tcpdump once the given size limit is reached instead of rotating?

If not, please let me know the version and the option that was introduced for this, stopping of tcpdump when file size is reached.

Because, I checked the source code of tcpdump-4.9.0 (http://www.tcpdump.org/#latest-releases) where I didnt find any file changes which is mentioned in this thread limit-file-size.
Also in the respective man page no info for this kind of functionality is found.

So please confirm on the version and the option that can be used.

In another machine we have tcpdump version as 4.8.1 also:
tcpdump version 4.8.1
libpcap version 1.8.1

Regards,
Sindhu.

[ky4k0b]

mpro-media-3-proto:~# tcpdump -i any -vvv -s0 --limit-file-size 100
tcpdump: unrecognized option '--limit-file-size'
tcpdump version 4.9.2
libpcap version 1.6.2
OpenSSL 1.0.1t  3 May 2016