This is used to select ringbuffer savefile name template. Choose one of two
savefile name templates:
If value is 1, make running file number part before start time part; this is
the original and default behaviour (e.g. log_00001_20210828164426.pcap).
If value is greater than 1, make start time part before running number part
(e.g. log_20210828164426_00001.pcap).
The latter makes alphabetical sortig order equal to creation time order, and
keeps related multiple file sets in same directory close to each other (e.g.
while browsing in wireshark "Open file" dialog).
Signed-off-by: Juha Takala <juha.takala+rauta@iki.fi>
Don't store the comments in a capture_options structure, because that's
available only if we're being built with capture support, and
--capture-comment can be used in TShark when reading a capture file and
writing another capture file, with no live capture taking place.
This means we don't handle that option in capture_opts_add_opt(); handle
it in the programs that support it.
Support writing multiple comments in dumpcap when capturing.
These changes also fix builds without pcap, and makes --capture-comment
work in Wireshark when a capture is started from the command line with
-k.
Update the help messages to indicate that --capture-comment adds a
capture comment, it doesn't change any comment (much less "the" comment,
as there isn't necessarily a single comment).
Update the man pages:
- not to presume that only pcapng files support file comments (even if
that's true now, it might not be true in the future);
- to note that multiple instances of --capture-comment are supported,
and that multiple comments will be written, whether capturing or reading
one file and writing another;
- clarify that Wireshark doesn't *discard* SHB comments other than the
first one, even though it only displays the first one;
Allows adding one or more capture comments to a new pcapng file when
tshark is reading from a file. Currently, tshark only allows setting one
capture comment, and that only when doing a live capture.
The use case for this feature is given in bug #15005.
I decided to allow multiple capture comments to match the same ability
in `editcap`.
To allow this change, I changed the function signature of
`process_cap_file()` so it takes a `capture_options` struct instead of
individual parameters that affect the capture.
The --log-debug and --log-noisy now accepts a '!' to invert the
match and disable the debug (noisy respectively) log level for
the listed domains.
Note this is different from --log-domains, that option
enables/disables the entire log domain itself, regardless of log
level.
Experience has shown that:
1. The current logging methods are not very reliable or practical.
A logging bitmask makes little sense as the user-facing interface (who
would want debug but not crtical messages for example?); it's
computer-friendly and user-unfriendly. More importantly the console
log level preference is initialized too late in the startup process
to be used for the logging subsystem and that fact raises a number
of annoying and hard-to-fix usability issues.
2. Coding around G_MESSAGES_DEBUG to comply with our log level mask
and not clobber the user's settings or not create unexpected log misses
is unworkable and generally follows the principle of most surprise.
The fact that G_MESSAGES_DEBUG="all" can leak to other programs using
GLib is also annoying.
3. The non-structured GLib logging API is very opinionated and lacks
configurability beyond replacing the log handler.
4. Windows GUI has some special code to attach to a console,
but it would be nice to abstract away the rest under a single
interface.
5. Using this logger seems to be noticeably faster.
Deprecate the console log level preference and extend our API to
implement a log handler in wsutil/wslog.h to provide easy-to-use,
flexible and dependable logging during all execution phases.
Log levels have a hierarchy, from most verbose to least verbose
(debug to error). When a given level is set everything above that
is also enabled.
The log level can be set with an environment variable or a command
line option (parsed as soon as possible but still later than the
environment). The default log level is "message".
Dissector logging is not included because it is not clear what log
domain they should use. An explosion to thousands of domains is
not desirable and putting everything in a single domain is probably
too coarse and noisy. For now I think it makes sense to let them do
their own thing using g_log_default_handler() and continue using the
G_MESSAGES_DEBUG mechanism with specific domains for each individual
dissector.
In the future a mechanism may be added to selectively enable these
domains at runtime while trying to avoid the problems introduced
by G_MESSAGES_DEBUG.
The distinction between the different kinds of capture utility
may not warrant a special subfolfer for each, and sometimes the
distinction is not be clear or some functions could stradle
multiple "categories" (like capture_ifinfo.[ch]).
Simplify by having only a generic 'capture' subfolder. The
separate CMake libraries are kept as a way to reuse object code
efficiently.
João Valverde