https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4573
Chad Dailey <wireshark@xxxxxxxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #2 from Chad Dailey <wireshark@xxxxxxxxxxxxxxxxxxx> 2010-03-19 13:45:45 PDT ---
The whole reason to have a 'ring' buffer is to allow continuous capture and
avoid disk space exhaustion, isn't it? If you can't specify at least two
options, the ring isn't a ring, it's a line pointing directly at a full disk
and a crash.
For example, if you specify a filesize and no secondary options can be set, it
will indeed roll to the next file at or near the specified size, but never stop
capturing. If you specify a number of files but no filesize, there is nothing
to indicate when the file is full and to advance to the next file.
Consider this snip of an example below:
C:\Program Files\Wireshark>dumpcap -i 2 -b files:10 filesize:10 -w
filename.pcap
dumpcap: Ring buffer requested, but no maximum capture file size or duration
were specified.
If files aren't a valid option, why are they indicated in the man page?
Filesize was indeed specified, why was it ignored? Seems awful arbitrary to
me.
A secondary reference:
tcpdump -C 10 -W 10 -w filename.pcap
In addition, the Wireshark Capture options in the GUI completely controvert
your assertion that there should be one option allowed, unless the definition
of a ring buffer is intended to be completely different. If that is so, I'd
suggest making it much clearer than the semantics of a few missing letters.
Here's from my dump of the options:
Output (files):
-w <filename> name of file to save (def: tempfile)
-b <ringbuffer opt.> ... duration:NUM - switch to next file after NUM secs
filesize:NUM - switch to next file after NUM KB
files:NUM - ringbuffer: replace after NUM files
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.