When splitting a possibly multifield custom column expression
into components, don't match "or" unless it's a word by itself,
i.e. is surrounded by space. "||" by itself is fine as a token.
This is necessary if we allow more complicated filters to match
than just single fields separated by "||" or "or". Also split
at space at the beginning or end of a string (since we don't
always guarantee that whitespace is stripped.)
When spliting into components, only split on "||" and " or " that
are not inside parenthesis. Splitting on operators inside parentheses
results in components which are not fields or valid filter expressions
and has never worked, e.g. splitting "(tcp.srcport or tcp.dstport)"
into "(tcp.srcport" and "tcp.dstport)".
TEST_OR has the lowest possible operator precedence (see
commit 34ad6bb478), so this works,
and also justifies using OR instead of AND for multifield custom
columns.
This means that, e.g., "tcp.srcport or tcp.dstport" will be treated
as a multifield custom column expression that returns the values
for both of the fields, whereas "(tcp.srcport or tcp.dstport)" will
be ultimately treated as a single logical test that returns true
if one of the fields exist and false if neither do. Until tests
and other non single-field expressions are supported, the latter
won't work, but it never has worked.
Related to #7752, #10154, #15990, #18588, and #16181.
* Change address comparison to `addresses_equal()`
* Change dissection to fixed packet length
* Proto column: Add space for distinction
* Change string encoding
* Change ID encoding
Add an opaque public type for stats_tree configurations. Get rid of
stats_tree_register_with_group and add stats_tree_set_group. Add
stats_tree_set_first_column_name. Convert some documentation to doxygen.
Use tvb_get_guint32() with xl_encoding, so that if the byte order is
ENC_LITTLE_ENDIAN, as it is for LINKTYPE_CAN_SOCKETCAN, it fetches the
field in little-endian order, while if it's ENC_HOST_ENDIAN, as it is
for Linux cooked captures, it' fetched in the host's byte order.
proto_tree_add_bitmask_list() is a bit of a pain if you want the values
of the field, so you have to fetch it yourself. It's little-endian, so
tvb_get_letohl(), not tvb_get_ntohl(), is the write routine to call.
For each field in the SocketCAN CAN XL pseudo-header, check if we have
all of the field and, if so, swap it, rather than just checking for the
availability of the complete header, just in case some packet is sliced
in the middle of the header.
Do this all with a bunch of offset/length #definitions, which also
means we don't have to worry about alignment or structure layout.
For WTAP_ENCAP_SOCKETCAN(LINKTYPE_CAN_SOCKETCAN), the only time any CAN
XL header would need byte-swapping would be with captures fom a
big-endian machine with current (but not upcoming) versions of libpcap.
Most captures are *probably* going to be on little-endian machines, so
that's probably not very likey - and the current byte-swapping
preference means "the ID/flags field is in *little-endian* byte order
and was done with a libpcap that didn't put it in big-endian byte
order", which means that, if it's necessary, it would be a separate
preferece. We'll add such a proference if it's ever necessary.
For dissect_socketcan_classic() and dissect_socketcan_fd(), those
dissectors probably shouldn't need to exist; the libwiretap modules that
use them should be changed to use WTAP_ENCAP_SOCKETCAN. In any case,
they're not used for CAN XL, so the CAN XL encapsulation argument they
pass is irrelevant.
For dissect_socketcan_sll(), the SocketCAN header is in *host* byte
order, with libpcap and libwireshark doing the usual byte-swapping dance
when reading a pcap or pcapng packet from a file or file section in the
opposite byte order from the machine reading the file (that needs to be
updated to handle CAN XL, and that's both a libpcap issue and a
libwiretap issue, each of which I'll address).
So, for now, don't use the byte-swapping preference to control the
encapsulatio for CAN XL.
Rename the prefrence to indicate what it does, namely control whether
the ID/flags field in the CAN classic/CAN FD header willl be
byte-swapped (and, by implication, what it *doesn't* do, namely control
whether fields in the CAN XL are byte-swapped).
The notifications that were added are for pNFS deviceid's, which
generally have a name in the spec like "notify_deviceid_type4". The
generic "notify" name is used for the directory change notifications.
Rename the old deviceid notifier functions and variables to a more
appropriate name.
Change-Id: Ibf80a41c7e2369bdd8ce669265cd549772a56338
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Instead of using g_strsplit, split the custom column format string
from the right. The ocurrence and "show resolved" tokens appear at
the end, but there could be a ':' internal to the filter, if we
later update what custom column filter strings are allowed in
order to support slices.
Necessary (but not sufficent) for #10154
When syn cookie support was added, a new tree was added under
the TCP timestamp option TSVal. Unfortunately, it was done
so by reusing the proto_item pointer that was pointing to the
tree item for the top level of the option, before it was done
having text appended to it.
Add a new proto_item pointer so that the text gets appended
to the original place.
Fixup acc0260c84
blf_pull_next_logcontainer() shuld check, aftre calling
blf_find_next_logcontainer() to see if the size of the
GArray of log containers is 0; if so, that means no log container was
found, probably because there aren't any to find.
This fixes a case where attempting to read a file with no log containers
causes a crash.
Put the priority and VCID into the Info column - and the top-level
protocol item.
And, again, don't fetch values in advance and set the Info column and
top-level protocol item text early. Instead, add each field to the Info
column and top-level protocol item when we add the field to the protocol
tree, so that if the frame is cut short, we dissect as much of it as we
can and put as much of it as we can into the Info column and top-level
protocol item.
Don't fetch values in advance and set the Info column and top-level
protocol item text early. Instead, add each field to the Info column
and top-level protocol item when we add the field to the protocol tree,
so that if the frame is cut short, we dissect as much of it as we can
and put as much of it as we can into the Info column and top-level
protocol item.
When generating DVFM code, tell the return function what
register has the final set of fvalues for filters that are
functions, arithmetic, or slices (that is, that compare one
or more fvalues to see if they are all zero.) Make sure
that these functions return an empty ptr array, unlike
tests that return a null ptr array.
For fields, we could return the fvalues, but currently we
don't bother loading the fvalues into registers since display
filters that just have a field test existence, so the generated
code would have to change. It's also a little more complicated
because there can be multiple fields that have different types
(sometimes not commensurable, which is an error noted by some of
the checks.) The logic in custom columns handles the field cases
currently.
Show all 8 hex digits for extended IDs, show all 3 hex digits for
standard IDs.
Also, show the length with %u, not %d, as it's unsigned (it won't be
bigger than 2^32-1, so that doesn't affect the output, but it's a better
type match.
The "flags" field in CAN classic and CAN FD is relly a "flags and ID"
field; rename appropriatey.
Rename can_..._flags_id_fd fields to canfd_..._flags_id, so as not to
mix up "flags_id" and "fd" - the latter refers to CAN FD, the former
refers to the two values in the item.
Allow subdissectors to register for particular CAN XL SDU types, e.g.
some Ethernet dissector (which one - the "always with FCS" one or the
"never with FCS done" - would depends on whether the FCS is included in
the tunneled frame; lacking access to the spec, I don't know which is
the case) would register in that table with the two tunneling types.
Provide SDU type #defines in packet-socketcan.h.
We don't need to read or use the column format string in
the recent settings column width info, because now they're
in sync with the indices used in prefs.col_list.
Continue to write it when writing out the recent settings for
backwards compatibility with older version.
We can also remove the workaround for #14177 from
commit c62dadd31f as it's
not needed.
This solves the width and alignment part of #15529. Hidden
states are still to do.
Those links are to questions with answers that indicate how to show a
folder window with a particular file selected using system APIs rather
than firing up programs.
Change the "fd" gboolean in can_info_t to a guint, and give it a value
of 2 for CAN XL. That preserves source and binary compatiility, at
least in the case where a plugin would never be handed a CAN XL frame.
Update code to treat it as such, to make it clearer what that code is
doing.
Add CAN XL support to the SocketCAN dissector - and to the
LINKTYPE_LINUX_SLL detector. Note that the fields in the
LINKTYPE_CAN_SOCKETCAN header for CAN XL frames are *little-endian*, as
most if not all existing captures were probably done on little-endian
machines - libpcap does that so that LINKTYPE_CAN_SOCKETCAN doesn't
become one of those annoying link-layer types with *host-endian* (as in
"the byte order of the host that last processed this file") fields
(which require special processing in pcap/pcapng file readers *and* in
rpcap clients).
If the CANFD_FDF flag isn't set, treat the frame as CAN FD if it's
exactly 72 bytes long; this works around a libpcap 1.10.{2,3,4} bug
(which should be fixed in the next libpcap release) that inadvertantly
cleared that flag for CAN FD frames.
Keep the recent column width list in sync with the order of the
prefs.col_list by appending, inserting, and moving the recent
column width list at the same time, instead of allowing them
to get out of sync (as we use the format for a key.)
Fix an issue where column_prefs_add_custom did not always return
the position of the column added (when a column number was passed
in that was less than the maximum number of columns.)
Preparation for the width and alignment part of #15529
Add the ability to change the width and alignment of columns
from the Column Preferences.
This also makes it easier to eventually fix#15529 by having all
the column-relevant details edited at once. In order to properly
solve that issue, the column indices from the preferences and the
recent settings need to be kept in sync, instead of using the format
as the unique key.
Related to #15529
Heuristics should not filter out packets that have destinationPAN ID != IEEE802154_BCAST_PAN, since GPD frames MAY inform PAN ID - GPD spec v1.1.1 section A.1.7.1.2 MAC addressing fields
The DCM tag/status/uid lookup tables are only ever read. const-ifying them
moves about 220 kBytes of data to a read-only data section.
packet-dcm.h was regenerated using the make-packet-dcm.py script.
The Well-Known Frames of Reference data have moved to Table A-2, so the script
is updated to integrate the data from that table into the UID list.
Ran "tools/make-packet-dcm.py > epan/dissectors/packet-dcm.h".
MR !14295 ran into trouble with the license checker because three added lines
in tools/make-packet-dcm.py moved the important piece of text outside the
150-line window in which it was checking.
This change maintains the status quo by expanding the window to 160 lines.
Pass the sysdig.param.asyncevent.data start and offset to the Falco Bridge
dissector, and use that to highlight the evt.buffer and fd fields.
Pass the data to the ELF dissector if we find an ELF magic ID.
John Thacker