interface_t contains an if_info_t as its member. It
doesn't need to copy the friendly name, vendor description,
and type from the if_info_t into separate members. The vast
majority of the time, we're already using the member from
the embedded if_info_t, but change a couple of cases.
The display name is a unique transformation of the name, friendly
name (OS name), and vendor description (hardware name) that depends
somewhat on the OS, so that needsto be seprate. The addresses and
links are also transformed from the if_info format. The name is
copied as well, but at least that's the primary key for the interface.
When rescanning the interface list (e.g. when manually refreshing
or a new device is added or removed), do not destroy old devices
but instead reuse it and preserve the user-set options.
Do check the monitor mode and active dlt setting against the
retrieved values to make sure that they are still supported.
In particular this means that the capture filter is not reset.
For many of the options, the value when creating a new device is
taken from the prefs, and the prefs are updated when the Capture
Options Dialog is closed (monitor mode, promiscuous mode, link layer
type, snapshot length, buffer size), or when the Manage Interfaces
Dialog is closed (hidden, user description), which mostly worked,
unless a refresh occurred when those dialogs were open and changes
had not been saved to prefs.
Fix#16418
In scan_local_interfaces(), we copying the information in the
if_info_t from the discovered interface list to the list of all
interfaces. Since we destroy the list of interfaces immediately
afterwards, rather than deep copying the if_info, we can shallow
copy it and remove it from the list.
Since we get both the non monitor mode and monitor mode
link types lists of interfaces that can support it, we can
allow the combination of retrieving the interface list and
capabilities at the same time, because we don't need the user
to specify whether to retrieve the list in or not in monitor
mode.
Allow any combination of retrieving the the interface list and
the two capability types to be retrieved, but don't allow them
in combination with the other run once arguments.
When not in machine readable mode, print the capability types
after the link lists (maybe we should interleave them). When
in machine readable mode, add them to the serialized JSON.
We don't yet pass both flags to dumpcap in capture child mode
from the other applications yet.
Related to #15082
This is slightly less efficient at the moment, but makes it easier
to change things to get and store the capabilities information
instead of repeatedly querying for it. Eventually we can retrieve
capabilities in the same dumpcap call as the interface list, and cache
the information.
Named pipes have special names on Windows
( https://learn.microsoft.com/en-us/windows/win32/ipc/pipe-names )
If we're on Windows, and the interface name given has such a name,
assume it is a pipe and don't bother retrieving the interface list.
Dumpcap and rawshark already have identical code for testing if an
interface name is a pipe. Move that into win32-utils and have
capture_opts, dumpcap, and rawshark all use the common function.
Fix#17721
If "-" is passed as the interface, don't bother spawning dumpcap
and retrieving the interface list. It's time-consuming and can
spawn a UAC on Windows depending on how NPcap is installed.
Also, set the description of standard input as done in
get_interface_descriptive_name. (We still possibly want to override
it with the -X option later.)
Part of #17721
get_interface_descriptive_name is slow, because it retrieves
the interface list. As called in tshark, it doesn't do anything,
because even though it changes interface_opts->descr, the
display_name is still set, so get_iface_list_string doesn't use it.
If the display_name were not set, then get_iface_list_string would
call get_interface_descriptive_name anyway. So either way it's
pointless.
We don't want get_iface_list_string to do extra interface list
retrievals by calling get_interface_descriptive_name in general,
but we probably do want to check the user-supplied description
(via prefs) and special user-supplied description of stdin (via -X),
which capture_opts fill_in_interface_opts_from_ifinfo doesn't do.
As it is, tshark makes extra retrievals of the interface list
and then doesn't do anything with the information.
Related to #16625
Do not read the capture filter list unless needed.
Do not use a static list because the capture filter list can change during program execution
and we want to be able to read multiple copies whenever.
Improve the public API function names.
When dumpcap or tshark are passed a `-b` option with an unrecognized
name, fail with an error message. This brings the behaviour in line with
how `-a` handles unknown options.
If `RINGBUFFER_MIN_NUM_FILES` is set greater than 0 in ringbuffer.h,
a logic error causes that number of files to be used regardless of the
user's desired number. Add braces to remove the logic error.
Do that rather than having that code directly call
capture_interface_list(), with the programs providing their own versions
of capture_interface_list().
Turn fill_in_interface_opts_from_ifinfo_by_name() into a routine,
find_ifinfo_by_name(), that just find an if_info_t for an interface by
name, and have its callre call fill_in_interface_opts_from_ifinfo() to
fill in the interface_options structure.
That centralizes the the fetching of the interface list and filling in
the interface_options structure in capture_opts_add_iface_opt(), rather
than doing it there *and* in fill_in_interface_opts_from_ifinfo_by_name(),
and simplifies the logic of find_ifinfo_by_name().
In preferences, we store interface names as: "friendlyname (name)".
Check for that formatting as well as for exact matches on just
the name or the friendly name on Windows.
Fix#16593.
Reduce the default update interval for dumpcap to notify its parent
of new packets (or to check if we've met file duration, etc.) from
500 ms to 100 ms, and put in the capture options.
This makes the GUI appear to update more in real time rather than
in visible batches of packets.
This also reduces the amount of ring buffer space needed in cases
where we're doing dissection, and dissection is able to keep up,
but the files can be deleted before tshark gets to them because of
the notification lag. (See #1650.)
The semantics behind ws_pipe_close() were broken since its introduction.
Forcing process termination on Windows, while simply setting variable on
other systems results in more OS specific code sprinkled all over the
place instead of less. Moreover ws_pipe_close() never handled standard
file handles. It is really hard to come up with sensible ws_pipe_close()
replacement, as process exit is actually asynchronous action. It is
recommended to register child watch using g_child_watch_add() instead.
Do not call ws_pipe_close() when deleting capture interface. Things will
break if extcap is still running when interface opts are being freed and
terminating process won't help.
Rework maxmind shutdown to rely on GIOChannel state. For unknown reason
TerminateProcess() is still needed on Windows. The actual root cause
should be identified and fixed instead of giving up hope that it will
ever work correctly on Windows. In other words, TerminateProcess()
should not be used as a pattern, but rather as a last resort.
Send SIGTERM on UNIX systems to all extcap processes when user requests
capture stop. Wait up to 30 seconds for extcaps to finish. If extcaps do
not finish in time, send SIGKILL to remaining extcaps.
Do not call TerminateProcess() on Windows in the same place where UNIX
SIGTERM is sent. Instead schedule extcap termination timeout to happen
as soon as control returns back to the event loop.
There is no universally agreed replacement for SIGTERM on Windows, so
just keep things simple (forcefully terminate like always) until we
have agreed on something.
Extcap child watch callback assumed that the stderr pipe is broken.
However the stdout and stderr pipes are not necessarily broken if the
child process spawned new processes that inherited standard handles.
Do not drain stderr in busy loop to prevent UI freeze. Stop capture
session only when all extcap watches are removed. Remove stdout and
stderr watches on capture stop timer (30 seconds) expiration, even if
the pipes are not broken.
Do not rely only on 0 bytes read to cease reading stdout and stderr.
Stop reading if the status is anything else than G_IO_STATUS_NORMAL
(especially it can be G_IO_STATUS_EOF).
Read extcap stdout/stderr data when available to prevent extcap hang on
stdout/stderr write. Discard stdout data as it was not used earlier.
Store up to 1024 bytes of stderr and display it to user after capture
stops.
Fixes#17827
Wait up to 30 seconds for extcap process to finish after closing pipes.
The wait is achieved in non-blocking fashion, i.e. the UI is completely
responsive during the wait. Only actions related to capture process like
capture control, file open, save, export are inactive during the wait.
On Windows extcap child watch callback gets called immediately as the
process is forcefully terminated. Prior to this change the extcap was
forcefully terminated on Windows anyway.
The wait is possible on UNIX systems if extcap does handle SIGPIPE and
SIGTERM signals. The defaults handlers for SIGPIPE and SIGTERM simply
terminate the process so for large number of extcaps there is no change.
If extcap does not finish within 30 seconds, it is forcefully terminated
using SIGKILL signal.
Don't use ZLib routines or data types if we're built without ZLib.
Don't support --compress-type=gzip, or a gzip check box in the Output
pane of the Capture Options dialog, if we're built without ZLib.
Fixes#17899.
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.
A domain filter can be given in the environment variable
'WS_LOG_DOMAINS' or in a command-line options "--log-domains".
The filter is specified as a comma separated case insensitive list,
for example:
./tshark --log-domains=main,capture
Domain data type switches from an enum to a string. There is no
constaint on adding new domains, neither in code or at runtime.
The string format is arbitrary, only positive matches will produce
output.
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.
In dumpcap, if we're being run by TShark or Wireshark, if there are no
link-layer types, just provide an empty list to our caller; let them
construct an empty list of link-layer types when they read our output.
In the code that reads that list, don't report an error if the list is
empty, rely on the caller to do so.
Have capture_opts_print_if_capabilities() do more work, moving some
functions from its callers to it.
It's not a generic capture option also supported by TShark and dumpcap,
it's Wireshark-specific (dumpcap *always* starts a capture, and TShark
starts one iff it's passed one or more interfaces on which to capture;
only Wireshark needs it to start the capture immediately - that's a
relic of the days when Wireshark *itself* did what dumpcap now does for
Wireshark).
Handle it in commandline_other_options(), rather than in
capture_opts_add_opt().
That lets us get rid of an argument to capture_opts_add_opt(), and dummy
variables in TShark and dumpcap used to work with that extra argument.
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.
Add --ifname and --ifdescr to allow the name and description for an
interface or pipe to be set; this overrides the specified name or
reported description for an interface, and overrides the pipe path name
and provides a description for a pipe.
Provide those arguments when capturing from an extcap program.
This is mainly for extcaps, so you have something more meaningful than
some random path name as the interface name and something descriptive
for the description.
John Thacker