For file sets produced by multiple file captures, match both
the number before time and the newer time before number format.
Distinguish them in the return value, since files of different
formats are not part of the same set.
Also handle files with a compression suffix as well, as we can
produce that in captures. Since in multi file captures compression
is done when switching files, allow file sets to have a mixture of files
compressed and uncompressed. When doing a multi file capture and
compressing, the last file is not compressed.
Add information to the user guide and release notes
Related to #12371
Instead of requiring ${macro:arg1;...;argN}, allow the format
${macro;arg1;...;argN}.
The semicolon isn't used anywhere else, it's simple to support,
and already used in the macro syntax. It's easier to remember
if all the separators in a macro are the same.
The colon is allowed in literals, which is why it's not used
between the arguments in the macro argument list, and allowing
it after the name makes the grammar more complicated, including
tokenizing when having pop-ups of potential field matches in
the display filter line edit (#19499.)
Update the documentation for this. Also edit the documentation
for macro syntax in a few places where it implies that whitespace
in macro arguments would be ignored; in fact, it's significant.
We've been planning on removing -G with no argument for
18 years (2f7fd680e2); start
warning users that it is deprecated.
Single letter options with optional arguments are tricky and
deprecated, see Guideline 12 of the POSIX Utility Syntax Guidelines.
( https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html )
We have special handling for -G as a result which forces it to the
first argument. -G with no argument can't be mixed with other options,
unlike the other reports. Removing this would allow relaxation of that
restriction.
Related to #17924
Remove the major.minor version from the plugin path, i.e:
lib/plugins/X.Y/{epan,wiretap,codecs}
and use an unversioned path:
lib/plugins/{epan,wiretap,codecs}
Introduce a new naming policy for plugins that requires
name.so.ABI_VERSION.
This is a simplified filesystem layoutfor plugins some
important benefits such as:
* improves compatibility between Wireshark versions, because
a plugin that wasn't recompiled will be automatically picked
up, but only if it has a compatible ABI version in the file name.
* does not clash with Apple guidelines
* simpler for users to understand and apply
* just overall simpler and easier to maintain, removes a lot
of complexity from CMake code
It does impose more requirements on the plugin naming scheme
but this should be handled completely transparently
by the build system.
It would also be possible to add support for unversioned *.so file
extensions at the same time, although in ths case it is not possible
to support multiple Wireshark ABI versions with only *.so, of course.
This wasn't done here but it may or may not be a useful enhancement
in the future.
Follow-up to 90b16b4092.
In general user customization should take higher priority
over system defaults. Do that here. This allows the user
to replace system plugins without much hassle.
We load the personal plugin folder first and lower the report
for a plugin found in multiple folders to a console log message
with log level "message" (so by default it will be displayed).
Add an option to the tools menu to copy a binary plugin file
(a .dll or .so) to the personal plugin folder.
This avoids the user having to create the paths manually and
knowning a lot of relatively unimportant details about where and
how Wireshark loads binary plugins.
It will also try to validate the plugin and do some sanity checks to
ensure the ABI is compatible.
Create a derived class for the TableViews to make it easier
to create the context menus.
Enable copying and saving only selected rows
Add release notes
Related to #16419
Instead of calling dumpcap separately for each interface in
the list, make one dumpcap call.
There's still two calls, one to get the list of interfaces and
one to get the capabilities, which is partly because interfaces
that support monitor mode can indicate support for different
link-layer types depending on whether monitor mode is enabled,
and we have to check per-interface preferences for the name to
see if we want monitor mode.
This roughly doubles the speed to add interfaces at startup
in my testing on Windows and Linux, and should massively
reduce the number of UAC pop-ups when npcap is installed with
restrictions to administrative access.
Fix#16191. Related to #15082 (it improves the number of UACs,
but perhaps they could be reduced even further by having dumpcap
stay open for all the calls in the life of the program.)
Add an alternative macro notation as $mymacro(a,b,c,d). For me
this notation is more natural, I have difficulty remembering how
to use macros with ${mymacro:a;b;c} and it makes the filter
expression harder to understand.
For convenience and to simplify the code we also allow
curly braces to open/close macro argument lists and the semicolon
as an argument separator for the new syntax.
This added flexibility may be reevaluated and dropped later if it
turns out to be undesirable for some reason.
Remove the UAT macro usage. The UAT API is nifty for dissectors
but clunky for everything else.
This allows using a hash table to store macros, that is the natural
data structure for the use case (and faster).
It also allows using the existing filter GUI dialog, adapted for
display filter macros. The difference isn't huge but it's better
and less limited than the more generic UAT dialog, with room for
improvement. Changing the UAT dialog for filter specific
use cases is difficult.
The config file is renamed to "dmacros" and uses the same format
as "dfilter", that is more amenable and forgiving for hand-editing
than the UAT storage format.
There is some logic to convert the "dfilter_macros" UAT config
file to a "dmacros" filter config file, for backward-compatibility.
The conversion is only done if there is no existing "dmacros" file
in the profile folder.
Add a display filter plugin with functions to test IP addresses.
This extends the display filter features with some more specialized
functions and serves as an example on how to write a display
filter plugin.
Allow references without braces, for a less cluttered syntax:
Filter:
frame.number > $frame.number
Instructions:
0000 READ_TREE frame.number -> R0
0001 IF_FALSE_GOTO 5
0002 READ_REFERENCE ${frame.number} -> R1
0003 IF_FALSE_GOTO 5
0004 ANY_GT R0 > R1
0005 RETURN
The original syntax of ${reference} came from macros but the
braces don't add much. In any case they are still allowed.
Allow writing display filter plugins in C. Plugins can
register one or more display filter functions.
This should lower the barrier for implementing and sharing
new display feature extensions.
An example plugin will be provided in a follow-up commit.
TODO: Put some work into refactoring display filter headers.
Right now some plugin-related APIs are implemented in dfilter-int.h,
which we'd rather not install to the system.
Allow plugins to declare their type, for the purpose of inserting
a description in the UI. The type consist of one or more bit ORed
flags.
This fixes the 'stats_tree' plugin description in the UI.
The plugin is not a dissector type plugin, as was being displayed
before. Now it correctly shows "tap listener" plugin.
Extend the time arithmetic to support multiplication and division
with floating point numbers.
In this case the multiplier/divisor is parsed according to its
lexical number type.
Fixes#19150.
The multiplication of two time values is not well-defined,
because time is represented internally as a vector.
Add a scalar multiplication/division for time values
using integer numbers. The scalar multiplier must appear
on the RHS of the operation. (This limitation mat be
removed in the future.)
This is useful to compare relative time values. The
operation is also allowed for absolute date and time values
because it is mathematically consistent but that is
probably less useful in practice.
Related to #19150.
Restore the type hierarchy for efficient loading of binary
plugins. Do not recurse.
Allow an exception for the root of the binary plugins
folder. Scan this path also and skip incompatible plugins.
This facilitates quick manual copying of plugins.
Follow-up to ef836e9afe.
The folder structure was introduced to organize the
plugins and permit more efficient loading during the
startup but the gains are slight and the requirement
is awkward to describe and easy to forget in practice.
Remove that requirement and load any compatible binary
plugin in the plugin folder. This also allows extra
flexibility to organize the plugins in categories,
for example adding an "external" folder for plugins
external to the project, or whatever else one might
wish.
To check for library compatibility we add an extra string
signature token in the plugin that can be compared with
the expected plugin type.
The downside is that the initialization is still performed
3 times and more files need to be skipped now but in practice
this should not have a measurable performance impact
and this eliminates a class of annoying small forgetful mistakes
when manually installing files.
This is still compatible with the old requirement of having a
epan/wiretap/codecs subfolder. At most one sublevel is allowed
to minimize security risks and slowness with any random folder
hierarchies if the plugins folder setting is somehow misconfigured
or hijacked.
Ping #19389.
John Thacker