tcpdump
tcpdump copied to clipboard
the-tcpdump-group
Add a flag (-R) to terminate capture after specified time
Context/Background: I needed this feature to be able to capture short bursts (single ms to tens of ms) on high-rate interfaces without packet loss. Searching produced some results of people trying to do timed captures using timeout(1) or other coarser-grained checks. OS-level checks rely on the running time of the program, not the time interval of packets captured, making it hard to capture short bursts. Alternatively, for multiple second captures, some people use the log rotation time + restriction of number of log files to take a timed capture, but this is both hacky and only provides resolution in seconds, not milliseconds or microseconds
Adding this check seems more reliable, easier to use, and provides finer-grained control than any of the above methods.
The check works by adding a function call to each of the callback functions passed to pcap; it saves the time of the first packet seen and then compares later packets to that time. Time interval is specified at as an argument to -R with units of microseconds, milliseconds, seconds, minutes, or hours. Internally, this gets converted to an integer number of microseconds.
Updated the generated manpage and the printed usage. Haven't added any tests; I didn't see any for other command line flags like -c, but can add a couple if desired.
-R was chosen as the flag as shorthand for "runtime"; the longopt is set to --max-runtime.
Needs a quick cleanup & rebase if the feature is of interest -- @infrastation how is that determined?
As another user points it out, there is the timeout command that does the job on the OSes traditional for tcpdump, so there are arguments pro and contra embedding timeout into tcpdump. Requesting more feedback on the tcpdump-workers mailing list would not be a bad idea, it seems to me.
Note that without an interval timer (setitimer()/alarm()) on UN*X, and an equivalent on Windows, there's no guarantee, on a network with a low level of traffic, that there won't be an arbitrary amount of time after the time expires when the capture terminates.
Note that without an interval timer (
setitimer()/alarm()) on UN*X, and an equivalent on Windows, there's no guarantee, on a network with a low level of traffic, that there won't be an arbitrary amount of time after the time expires when the capture terminates.
Yeah, very true. Thoughts on adding an interval timer equal to the selected time +1 second (or something equally "long" relative to a short time selection)?
Can you use a long option?
--max-runtime is a substitute for -R in the code as is
