If the capture.no_extcap preference is set, really don't load the
extcap interfaces. Previously, the extcap interfaces were loaded
before the preference was read, because otherwise the extcap
preferences wouldn't be registered and properly read out of the
configuration file.
Wait until after that preference is read to register the
extcap preferences and then re-read just the extcap module
preferences from the configuration files. Make sure to check
other times when the preference may be changed, such as
switching profiles.
Write extcap prefs to a separate file so that they don't get lost
if the extcap interfaces aren't loaded and the prefs are then
written out. Continue writing them to the main file for backwards
compability.
Related to #15295. Cuts ~100 ms off the loading time of Wireshark
in a normal situation if the capture.no_extcap preference is set,
more if an extcap has some kind of issue that makes it take a long
time to load.
Implement checking the ESP ICV when Extended Sequence Numbers are
used. Add some entries to the UAT, with forwards compability, for
the sequence number size, which is transmitted out of band.
Fix#19658
Remove CFBundleGetInfoString, which is deprecated, in favor of
NSHumanReadableCopyright. Use the same organization name there as we do
in our Windows resource files.
Ping #14407
The solution to #12331 makes command line options that change
preferences be reapplied when reloading Lua plugins.
The command line preference overrides should be either reapplied
or dropped when changing configuration profiles. Doing neither,
as currently, means that they are not reapplied when switching
but are reapplied when subsequently reloading Lua plugins, which
is confusing. Drop them, but we could change that decision.
Make sure that we set the pointer to NULL when freeing so that
we don't double-free.
commandline.h requires cfile.h to get the search direction enum.
Rather than shelling out to "osascript" and telling it to tell Finder to show
the file, we can directly use NSWorkspace's "activateFileViewerSelectingURLs:"
method to launch Finder and highlight the chosen file. It's less code, runs
faster, and should be much less risky regarding special characters, string
encodings, etc.
extcap_foreach no longer exists. The extcap_cb_t is used with
extcap_run_one, and when operations are needed on multiple
extcaps they are run in parallel in multiple threads, since each
operations requires spawning a process.
Update the comments to note this, and that the return value is
no longer used.
Allow cb_preference to take a NULL for the pointer to a list
of arguments. If the pointer is NULL, then free the argument list.
This keeps extcap_load_interface_list from creating a list that
is immediately freed.
On Linux (and presumably other DBus-using Unix-like OSes), right-clicking on a
file on the Welcome page and choosing "Show in Folder" would only ever open the
folder, and would not highlight the chosen file.
Adding DBus support to function desktop_show_in_folder allows for the file
itself to be shown -- subject to support from the user's desktop environment...
Read the old obsolete hidden column preference and apply it.
This will convert it to the new value (and remove it) if preferences
are saved.
Follow up to 41930060b0
Allow anything that can be used in a display filter to be used in
columns (with the exception that field references don't work without
a notion of a currently selected frame): display filter functions,
slices, arithmetic calculations, logical tests, raw byte addressing,
the layer modifier, display filter macros, etc., alone or in
combination.
Show the results and generate filters. Note that "resolved" values are
not yet supported. They make conceptual sense for some expressions
(e.g., if the layer modifier only is used) but not for others.
Perhaps resolution could be done as a final step in the filter before
returning values.
It would also be useful to be able to get the expected return type
of an expression, so that the functions for right justifying a column
or sorting numerically could work. Right now the results are treated
as strings even if the return field values are numeric.
Multifield columns (i.e., concatenation of field values) are currently
implemented using the OR operator.For backwards compability, continue to
support that. When a true logical OR would give a different result,
surround the expression in parentheses, which the multifield columns did
not previously support (due to the regex used instead of full filter
grammar parsing.)
Perhaps in the future we should introduce a separate operator for
concatenation, possibly only used in column definitions and nowhere
else.
Update release notes.
Fix#7752. Fix#10154. Fix#15990. Fix#18588. Fix#19076.
Related to #16181 - it's now possibly to define new display filter
functions so that is essentially solved, though I suppose there's
always room for more built-in functions.
The register and coil numbers are a sequence of numbers starting from
the desired number (first register). This revision will change
the register item to a generated one without a direct link to the data.
Decode data in the function Write Single Register/Write Multiple Coils
to Value.
Fix bitmask for boolean value in Read/Write Coils/Inputs.
Closing #19635
Change our menu path separator to "//" similar to our filter buttons.
Change the "name" configuration element to "path", since it's a menu
path. Add a separate "title" element. This lets us use names like "Foo
I/O".
Since DRBD 9.2.6, a load-balancing transport is available for DRBD. This
is called "lb-tcp". Add support for dissecting this format.
This transport is a wrapper around the plain DRBD format. Each lb-tcp
packet contains part of this DRBD stream. The DRBD packets may be broken
across multiple lb-tcp packets. Conversely, one lb-tcp packet may
contain multiple DRBD packets.
One lb-tcp connection consists of multiple TCP streams. We cannot rely
on having all of these streams in the capture. Even when we do, it is
difficult to associate them with each other. Hence we decode each TCP
stream separately and accept that we may not be able to dissect every
DRBD packet fully.
In practice, most lb-tcp payloads do start on a DRBD packet boundary, so
the result is still very usable.
Many of the generated "const" fields can be made static. For local variables,
this means that the compiler will no longer emit code to allocate the structure
on the stack and initialize it upon each function entry -- 29 kBytes of code in
total gets removed by this change -- which is surely a performance win when
dissecting this protocol.
Interestingly, libwireshark.so ends up growing overall due to the addition of
52 kBytes of relocation entries to patch up references within the relocatable
read-only data section. Clearly the generated code was more space-efficient
than the relocation entries...
The X11 dissector was manually updated to static-ify some symbols, but this was
done without updating the scripts used to generate that dissector.
Let's temporarily roll back those changes so we can cleanly update the X11
dissector.
WTAP_ENCAP_SOCKETCAN suffices, and doesn't add a bunch of upper PDU tags
that provide no additional information.
While we're at it, rename candump_write_packet() to
candump_gen_packet(), as it doesn't write anything to a file.
Run `launchctl bootout` prior to running `launchctl bootstrap`. This
should hopefully avoid the error
Bootstrap failed: 5: Input/output error
if we're already bootstrapped and keep the postinstall script from
failing.
Fixes#19527
In many grammatical contexts fields are only tested for existence
instead of loading the values into a register, because that's all
that is needed to determine if a filter passes or not. Add a
dfilter option to load the field values from the tree and return
them when a field (including field at a certain protocol layer) is
the root of the filter syntax tree.
This is useful for columns, especially for parsing columns defined
with the layer operator, but it can't completely replace the current
custom column handling because we don't yet return exactly which
hfinfo was present, if more than one has the same abbreviation, and
it's possible for fields with the same abbreviation to have different
strings, and hence different "resolved" values.
$ ./run/dftest -s "@ip.proto#1"
Filter:
@ip.proto#1
Syntax tree:
0 FIELD(@ip.proto#[1:1] <FT_BYTES>)
Instructions:
0000 CHECK_EXISTS_R ip.proto#[1:1]
0001 RETURN
$ ./run/dftest -s "@ip.proto#1" --return-vals
Filter:
@ip.proto#1
Syntax tree:
0 FIELD(@ip.proto#[1:1] <FT_BYTES>)
Instructions:
0000 READ_TREE_R @ip.proto#[1:1] -> R0
0001 NO_OP
0002 RETURN R0
Related to #18588
John Thacker