Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
Coverity CID 1592124
|
|
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.
|
|
Fix a (cut and paste?) error adding check marks to the wrong
expression for FT_NONE and FT_PROTOCOL in resolved vs unresolved
|
|
|
|
Some of the functions in proto.c when handling a FT_BOOLEAN field
allow it to be part of a 64 bit unsigned integer with a 64 bit
bitmask. Other functions do not. Some of the functions start out
allowing a 64 bit bitmask and then switch to casting the value to
a 32 bit unsigned integer (but others don't.) Consistently allow
a boolean to be extracted using a 64 bit bitmask by changing the
various proto_tree_add_boolean functions to allow a 64 bit unsigned
integer value parameter.
There was only one function adding a boolean that already took
a 64 bit value, proto_tree_add_boolean_bits_format_value64, a
counterpart of proto_tree_add_boolean_bits_format_value. It was
never used anywhere and not WS_DLL_PUBLIC, so it is safe to remove
in favor of having the latter take a uint64_t.
Note that _proto_tree_add_bits_format_value, as a comment says:
"does not receive an actual value but a dimensionless pointer to that value.
For this reason, the type of the header field is examined in order to determine
what kind of value we should read from this address.
The caller of this function must make sure that for the specific header field
type the address of a compatible value is provided."
Both proto_tree_add_boolean_bits_format_value and
proto_tree_add_boolean_bits_format_value64 called that function, one
passing a pointer to a guint32 as a void*, the other passing a
pointer to a guint64. In both cases it was cast to a guint32*, which
was less than ideal in the value64 case. Fix that.
This is related to #19552, as it is necessary in order to add support
for passing a UInt64 value to a boolean field (as oppposed to extracting
it directly from the tvb.)
|
|
If a field_info is visible, we don't fake the representation and
allow the representation and length to be set after construction.
Therefore, when trying to add a child item to a tree item that has
a visible field_info, we can't fake the child node and return the
current tree node.
If we do, we can't distinguish between an attempt to set the length
or representation of the current tree item, and an attempt to set
the length or representation of the faked child (or its descendent)
because they'd both have the same node.
Since we need the lengths of protocol items for the proto hierarchy
stats (and many protocols are added with length "to the end of the
frame" and then fixed later), if we're not faking protocols, don't
set a protocol field info to hidden even if the tree is not visible.
There are probably still some issues related to the use of
proto_item_get_parent[_nth]. We might have to avoid faking nodes for
any lineal descendent of an item whose representation we need.
Related to #19619 (fixes some handling of MATE ranges),
related to #19573 (fixes getting the representation of certain items that
are also subtrees and have children that set their representation), and
fixes the Protocol Hierarchy stats issue in #17877.
|
|
Show truncated fields as "Field name […]: data" instead of "Field name
[truncated]: data". This lets us show a few more characters of data.
|
|
Add a new hfi reference type for when we're printing items,
that supersedes direct reference - in addition to ensuring that
we don't fake an item, it also defaults the item to visible
(doesn't mark it as hidden when the tree isn't visible), so
that the string representation isn't faked either for fields
that have non-default formats.
Use it when fields are specified with -e; instead of setting
the entire tree as visible, only mark visible the items that
we want to print. This speeds up tshark -e output with all the
-T options that support it, sometimes by 2 to 4 times.
Part of #19573
|
|
proto_tree_add_text_valist_internal calls proto_tree_add_text_node,
which calls proto_tree_add_pi() with the internal hf_text_only FT_NONE
item, which calls get_hfi_length which does the adjustment of the
length to be either everything in the tvbuff (if length is -1), or
the minimum of what's in the tvbuff and the length (if length is not -1
and we have the tvbuff.)
This proto_tree_add_text_valist_internal doesn't need to do its own
version of the check. In particular, this means when adding a
text-only subtree with a tvb truncated with capture, the subtree
will be added truncated and the exception will be thrown when
retrieving the first unavailable item, instead of throwing the
exception immediately.
This is the behavior already done when adding FT_PROTOCOL and FT_NONE
items via other methods.
Related to #19544
|
|
See
1. https://www.tcpdump.org/linktypes/LINKTYPE_NFLOG.html
2. The `nla_put(inst->skb, NFULA_TIMESTAMP, sizeof(ts), &ts))`
call in net/netfilter/nfnetlink_log.c in the Linux kernel source.
Add support for 16-byte and 12-byte seconds/microseconds time stamp, to
match what we already have for seconds/nanoseconds time stamps, in
`proto_tree_add_item()` etc., and use that.
Fixes #19525.
|
|
Store whether or not heuristic dissectors are enabled by default.
When reenabling protocols to their initial state, such as when
changing profiles, also set heuristic dissectors back to their
initial state.
Also use the initial state in dissector_dump_heur_decodes so
that it correctly displays the default state of a heuristic
dissector, even if the heuristic dissector has been changed from
the default.
Fix #19520
|
|
|
|
Remove init of proto, header field, expert info and subtree variables.
This will reduces the binary size by approximate 1266320 bytes due to
using .bss to zero-initialize the fields.
The conversion is done using the tools/convert-proto-init.py script.
|
|
There's been an assumption that INT32 based fields won't need
labels longer than 32 bytes, and INT64 based fields no longer
than 48. Buffers are declared to hold the integer labels.
These buffers are all intermediate buffers allocated on the stack
and used in static functions; none of them are the final returned
label, which is ITEM_LABEL_LENGTH.
BASE_OUI can require 64 bytes at most for the manufacturer string
(including null), plus 11 extra bytes for the "XX:XX:XX ()" part.
(Service names for port numbers ought to be limited to
15 characters, https://www.rfc-editor.org/rfc/rfc6335#section-5.1 )
Define NUMBER_LABEL_LENGTH and make it 80 bytes. That's smaller
than ITEM_LABEL_LENGTH (240); it could be increased to ITEM_LABEL_LENGTH
without trouble if necessary; using a #define make it easier to do so.
Fix #18069.
|
|
Update epan to not initialize static proto values to -1.
|
|
Add a script to initialize static proto values to 0 instead of -1.
This will save ~1MB static init code.
|
|
|
|
For custom columns, use the available column width. For display
items, use the item width.
Note that the bytes_to_str_maxlen functions take as parameter the
number of bytes to display, so divide the string length by 2 or 3,
depending on if we're using a separator.
Labels and columns already have truncation mechanisms, so we
can use that after passing in the full available widths.
Fix #14265
|
|
Fixes 0d46d9a60a89b8d2fd37c91515f3c8153b5e6b99.
|
|
Do not allow "fvalue_set_uinteger" and "fvalue_get_uinteger"
with FT_IPv4. Use "fvalue_set_ipv4" and "fvalue_get_ipv4"
intead.
Fix incorrect usage of fvalue_*_uinteger with FT_IPv4,
hopefully I caught all of them.
|
|
It's more compact than "bitwise_and" and inspired by C.
|
|
In the NTP time encodings described by RFC 5905, "a value of zero is
a special case representing unknown or unsynchronized time." As put
by RFC 4330, "There will exist a 232-picosecond interval, henceforth
ignored, every 136 years when the 64-bit field will be 0, which by
convention is interpreted as an invalid or unavailable timestamp."
The check for the zero value needs to occur *before* converting
the fractional part of nanoseconds. Otherwise, four of the additional
232 picosecond intervals as unknown are truncated to 0 nanoseconds
and incorrectly treated as unknown time.
While it's unlikely that many clocks have a precision of 232
picoseconds, it's possible that an implementation that knows about
how time is handled would intentionally use 0x00000001 for the
fractional part so as to avoid indicating an unknown time.
For the ENC_TIME_MSEC_NTP time, handle the alternative where the upper
bytes are used for storing NTP Era information instead of being
unused. Also require it to use at least 6 octets, as specified in
ETSI TS 129.274, as fewer than 6 octets for an absolute time in
milliseconds can only express less than 35 years.
Also add a few other comments, e.g. that ENC_TIME_SECS_NTP should
be used instead for the time without fractional seconds.
Fix #18174
|
|
Rename a typedef and use an address and mask as the method
interface.
|
|
Mask off the field display when checking string-like fields,
the same as done for FT_BYTES and others, so that
BASE_NO_DISPLAY_VALUE is allowed for string-like fields.
This is useful for protocols that have large text payloads with
known encodings that are used as header fields above a subtree
or as payload fields, where it might be useful to access the
entire string value, e.g. from tshark output, in the same way
as byte arrays.
Use this in SIP, where the same effect is currently being achieved
by calling proto_item_set_text after creation with the field name.
|
|
Add the missing parameter to get_manuf_name_if_known() to fix
a compile error.
|
|
Create a public function in `epan/proto.c` to dissect a single MAC-48
address. Encapsulates the name and OUI resolution, and the LG and IG
bit parsing.
Created after observing that `packet-ieee80211.c` does not resolve the
OUI or IG/LG bits for WLAN fields (`wlan.ra`, `wlan.da`, `wlan.sa`,
`wlan.bssid`) the way that `packet-eth.c` does.
This change modifies `packet-eth.c` and `packet-ieee80211.c`
to use the new function.
Add IG/LG bits
|
|
Instead of adding a TFS(&tfs_true_false) to every boolean
field, make it the default if "strings" is NULL.
This seems to match the already existing documentation:
If the Boolean field is to be displayed as "False" or "True", the
'strings' field would be set to NULL.
|
|
Add a cleanup function in proto_tree_new_item for the newly
created field_info's fvalue_t, so that if we throw an exception
before adding the new node to the tree, the fvalue_t is properly
freed. Pop it off without calling it if we do add the node.
This is the function that adds nodes from values retrieved from
the tvbuffer, so it can throw exceptions, particularly on variable
length items like FT_STRINGZ, VARINTs, and FT_UINT_[STRING|BYTES].
|
|
Normally field_info values added to the tree are freed in
proto_tree_free_node.
If proto_tree_add_node fails, and the passed in field_info is
not added to a new node of the tree, free the field_info fvalue
there so it doesn't leak.
|
|
Fix a couple leaks:
Free the created GByteArray in the case where the encoding is not
FT_STRING and the tree is non NULL. (We need to create it if the
return value is non NULL, but don't really need to create it
otherwise.)
For FT_UINT_BYTES, don't create the GByteArray until we ensure
that the entire length exists, not just the header length, so
we don't leak it if we throw an exception verifying the entire
length.
|
|
There is no reason to have separate "RFC 822" and "RFC 1123" parsing of
Internet Message Format date/time values. RFC 1123 adds support for
4-digit years to RFC 822's 2-digit years; RFC 2822, which supplanted RFC
822, supports both, and RFC 5322, which supplanted RFC 2822, continues
to do so. I know of no cases where *only* 2-digit years should be
supported, especially given that it has beenover 23 years since January
1, 2000.
Instead, have ENC_IMF_DATE_TIME for Internet Message Format date/time
values; keep ENC_RFC_1123 for backwards compatibility, but treat it
exactly the same as ENC_IMF_DATE_TIME. Keep ENC_RFC_822 around as an
alias for ENC_IMF_DATE_TIME.
Have separate expert infos for errors parsing string-encoded byte arrays
and string-encoded dates and times, with the messages speaking of byte
arrays and dates/times rather than "numbers". For now, have the only
error being "couldn't convert"; we can add more for specific cases of
what's wrong.
In tvb_get_string_bytes() and tvb_get_string_time(), don't use errno as
a way of indicating failure, use a return of NULL. Using errno 1) runs
the risk of getting errno overwritten by intermediate calls and 2)
would force assinging particular errno values, the set of which we don't
control, to particular errors if we were to distinguish different errors
in the future.
In tvb_get_string_time(), for Internet Message Format date/time values,
check for 2-digit and 3-digit years based on the length of the year
field in the string. Handle them the way the RFCs say, not the way
strptime() does (strptime(), which was originally written to allow
programs to ask the user to specify a date and time and let them enter
it in the locale's date and time format, and to use 2-digit years in
case they were in the habit of doing so, which they might have been
given that this was the mid 1980's; the choice of 1969 as the first "not
21st century" year was based on the fact that it was the earliest year
for a date correspnding to a non-negative time_t value, which is
UNIX-specific, unlike the Internet Message Format).
Change tvb_get_string_time() to use guard clauses to handle errors; yes
it involves gotos, but it's easier to read than nested ifs, for example.
Update the Lua unit tests to reflect this.
|
|
Adds "nan" (not a number) and "inf" (infinity) as reserved keywords,
to avoid clashes with protocols that want to use these filter names.
Filter:
_ws.ftypes.double == nan
Instructions:
0000 READ_TREE _ws.ftypes.double <FT_DOUBLE> -> R0
0001 IF_FALSE_GOTO 3
0002 ANY_EQ R0 == nan <FT_DOUBLE>
0003 RETURN
Filter:
_ws.ftypes.double == -inf
Instructions:
0000 READ_TREE _ws.ftypes.double <FT_DOUBLE> -> R0
0001 IF_FALSE_GOTO 3
0002 ANY_EQ R0 == -inf <FT_DOUBLE>
0003 RETURN
|
|
When parsing an expression such as
Filter:
_ws.ftypes.boolean == true
Instructions:
0000 READ_TREE _ws.ftypes.boolean <FT_BOOLEAN> -> R0
0001 IF_FALSE_GOTO 3
0002 ANY_EQ R0 == 1 <FT_UINT64>
0003 RETURN
it gives the wrong type. Conceptually there is no reason a boolean
should be a value string.
This commit also fixes the error message to avoid calling invalid
boolean tokens "invalid numbers" when parsing booleans.
The code now use g_ascii_strcasecmp() to accept true, True, trUE, etc.
Initially the intention was to require non-numeric literals to
start with an upper-case letter, to reserve lower-case for protocol
names, but since "true" and "false" have been accepted as integers
for a long time via value strings, that intention is dropped.
As a consequence true/false are added to reserved keywords.
After this change:
Filter:
_ws.ftypes.boolean == true
Instructions:
0000 READ_TREE _ws.ftypes.boolean <FT_BOOLEAN> -> R0
0001 IF_FALSE_GOTO 3
0002 ANY_EQ R0 == 1 <FT_BOOLEAN>
0003 RETURN
|
|
This commit adds new fields to the output of both `-G protocols` and
`-G heuristic-decodes` in `tshark`.
For `-G protocols`, three new fields (4, 5 and 6) have been appened to
the existing ones:
- Field 1: protocol name
- Field 2: protocol short name
- Field 3: protocol filter name
- Field 4 (NEW): protocol enabled (e.g. "T" or "F")
- Field 5 (NEW): protocol enabled by default (e.g. "T" or "F")
- Field 6 (NEW): protocol can toggle (e.g. "T" or "F")
For `-G heuristic-decodes`, similarly three new fields (4, 5 and 6)
have been appended to the existing ones:
- Field 1: underlying dissector (e.g. "tcp")
- Field 2: name of heuristic decoder (e.g. "ucp")
- Field 3: heuristic enabled (e.g. "T" or "F")
- Field 4 (NEW): heuristic enabled by default (e.g. "T" or "F")
- Field 5 (NEW): heuristic short name (e.g. "ucp_tcp")
- Field 6 (NEW): heuristic display name (e.g. "UCP over TCP")
The new fields added to `-G heuristic-decodes` are useful as the short
name argument required for `--enable-heuristic` was not previously
shown in the `-G heuristic-decodes` output.
|
|
Commit af0691342b7e6bc2ef81a8430ae00680223337bc and
commit 80ae370811595f294c65cb71e1d213d5b49e33fd both added
proto_disable_all.
Take the one from the 80ae370811595f294c65cb71e1d213d5b49e33fd,
which made changes to allow protocols to be enabled by
proto_enable_proto_by_name() even if they are not disabled by
default, which allows --only-protocols to work without changing
the disabled-by-default setting of a protocol.
We don't want to change the disabled by default setting, because
that causes the disabled status to be persistent even when
changing Configuration Profiles with the GUI, instead of being
reset. In general, command line options that temporarily override
the Configuration Profile at startup are cleared when switching
to a new profile via the profile, and we don't want to make an
exception.
|
|
--disable-all-protocols will mark all protocols as disabled by default,
and then disable them. Certain protocols can then be enabled one by one
by using --enable-protocol.
--only-protocols is a helper option to make it easier to enable only
certain protocols It's equivalent to passing --disable-all-protocols and
then several --enable-protocol options. It accepts a comma separated
list of protocols. First all protocols will be disabled, and then all
protocols included in the list will be enabled one by one.
Side-note, it wouldn't make much sense to enable only "tcp" for example
without enabling the protocols in the lower layers (e.g: eth, sll, ip,
ipv6). In this case, something like --only-protocols eth,sll,ip,ipv6,tcp
will generally be needed in order to make sure that TCP is decoded.
Signed-off-by: Juanma Sanchez <juasanch@redhat.com>
|
|
|
|
|
|
|
|
Make the text of each registered column a FT_STRING field that can be
filtered, prefixed with _ws.col - these work in display filters, filters
in taps, coloring rules, Wireshark read filters, and in the -Y, -R, -e,
and -j options to tshark. Use them as the default "Apply as Filter" value
for the columns that aren't handled by anything else currently.
Because only the columns formats that actually correspond to columns
get filled in (invisible columns work), register and deregister the
fields when the columns change.
Use the lower case version of the rest of the COL_* define for each
column as the field name.
This adds a number of conditions to "when are the columns needed",
including when the main display filter or any filter on a tap is
using one of these fields.
Custom columns are currently not implemented. For custom columns, the
tree then has to be further primed with any fields used by the custom
columns as well. (Perhaps that should happen in epan_dissect_run() -
are there any cases where we construct the columns and don't want to
prime with any field that custom columns contains? Possibly in taps
that we know only use build in columns.)
Thus, for performance reasons, you're better off matching an ordinary
field if possible; it takes extra time to generate the columns and many
of them are numeric types. (Note that you can always convert a non-string
field to a string field if you want regex matching, consult the
*wireshark-filter(4)* man page.) It does save a bit on typing (especially
for a multifield custom column) and remembering the column title might
be easier in some cases.
The columns are set before the color filters, which means that you
can have a color filter that depends on a built-in column like Info or
Protocol.
Remove the special handling for the -e option to tshark. Note that
the behavior is a little different now, because fixed field names
are used instead of the titles (using the titles allowed illegal
filter names, because it wasn't going through the filter engine.)
For default names, this means that they're no longer capitalized,
so "_ws.col.info" instead of "_ws.col.Info" - hopefully a small
price in exchange for the filters working everywhere.
The output format for -T fields remains the same; all that special
handling is removed (except for remembering if someone asked for
a column field to know that columns should be constructed.)
They're also set before the postdissectors, so postdissectors can
have access.
Anything that depends on whether a packet and previous packets are
displayed (COL_DELTA_TIME_DIS or COL_CUMULATIVE_BYTES) doesn't work
the way most people expect, so don't register fields for those.
(The same is already true of color filters that use those, along with
color filters that use the color filter fields.)
Fix #16576. Fix #17971. Fix #4684. Fix #13491. Fix #13941.
|
|
ws_label_strcpy, like strlcpy, returns the number of bytes it
would have written in the case of overflow.
proto_item_fill_display_label needs to return the actual number
of bytes copied (which is what protoo_strlcpy does).
Fix #19212
|
|
Added an option for checking the expected RTPS message
checksum is the same as the received in the wire if
checksum is CRC-32C or MD5. Also delted unused header filters.
Introduced function proto_tree_add_checksum_bytes.
|
|
Fixes #19186.
|
|
Remove the requirement for a space character to precede a
minus token.
Fixes #19189.
|
|
Add ABSOLUTE_TIME_UNIX absolute time type, to allow
date and time values to be represented in Unix time,
besides other existing formats.
|
|
Do not mix wire size, a protocol property, with fvalue
length, a property of certain types of objects (sequences).
Rename ftype_length() to ftype_wire_size(). Do not return
wire_size with fvalue_length() (use ftype_wire_size()
instead).
Make the semantic check reject taking the len() of objects
that are not arrays or lists. If the (fixed) len() of a number
is somehow useful we can add a different function for that.
|
|
Rename IS_FT_*() to FT_IS_*(). I find it to be more natural and
a better namespace for a public interface.
|
|
snprintf(), sensibly, takes a size_t argument specifying the size of the
buffer. g_snprintf(), bogusly, takes a gulong argument specifying the
size of the buffer, so we had to do casts to avoid narrowing complaints,
but we're just using snprintf() now (as we require C11 or later), and
don't need the casts any more.
|