Develpment headers are a sizeable part of the binary installation
and most users won't ever require them. It's recommended to package
them separately in a devel package or SDK.
Create a CMake installation component for development headers
and add the EXCLUDE_FROM_ALL property.
Headers can be installed using the invocation:
cmake --install <dir> --component Development
Make dfilter byte representation always use ':' for consistency.
Make 1 byte be represented as "XX:" with the colon suffix to
make it nonambiguous that is is a byte and not other type,
like a protocol.
The difference is can be seen in the following programs. In the
before representation it is not obvious at all that the second
"fc" value is a literal bytes value and not the value of the
protocol "fc", although it can be inferred from the lack of
a READ_TREE instruction. In the After we know that "fc:" must
be bytes and not a protocol.
Note that a leading colon is a syntactical expedient to say
"this value with any type is a literal value and not a protocol
field." A terminating colon is just a part of the dfilter
literal bytes syntax.
Before:
Filter: fc == :fc
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(fc <FT_PROTOCOL>)
1 FVALUE(fc <FT_PROTOCOL>)
Instructions:
00000 READ_TREE fc <FT_PROTOCOL> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == fc <FT_PROTOCOL>
After:
Filter: fc == :fc
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(fc <FT_PROTOCOL>)
1 FVALUE(fc: <FT_PROTOCOL>)
Instructions:
00000 READ_TREE fc <FT_PROTOCOL> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == fc: <FT_PROTOCOL>
The ftype itself is encoding agnostic. In the case of literal
display filter strings it is possible and legal to contain
invalid UTF-8.
Maybe it shouldn't be but that requires a user-friendly diagnostic
message, not silently sanitizing the string as is done currently
(only a debug message is printed in that case).
Do the debug checks in proto_tree_set_string() instead. That
still detects dissector code that might need fixing, which was
the purpose for this check.
Improve documentation and add admonition for proto_tree_add_string().
Ping #18521.
Replace strtol/strtoul with the glib functions that do
not have a locale dependency.
Cleanup some casts and print formats. Remove some code
duplication. Add some null checks.
Rename a function for consistency.
Using a warning is probably too exalted for the current state
of the code, where UTF-8 errors are somewhat expected from
dissectors that are lax about input validation.
Use a debug level with its own "UTF-8" domain instead.
Using a dedicated domain allows to filter on encoding errors and
with some enhancements to the logging subsystem make them fatal
for tracking and debugging purposes.
Using a dedicated domain might have other drawbacks but for now
it seems like the best approach.
Some older dissectors that predate Unicode and parse text protocols
are prone to generate invalid UTF-8 strings. This is a bug and can have
safety implications.
For example passing invalid UTF-8 to proto_tree_add_string() is a
common bug. There are safeguards in format_text() but this should
not be relied on as a general solution to the problem.
For one, as the name implies, it is only used with representation of a
field value, which is not the same as the value itself of an FT_STRING field.
Issue #18317 shows another reason why.
For now this compile flag only enables extra checks for string ftypes,
which covers a subset of proto.h APIs including
proto_tree_append_string(). Later is should be extended to other
interfaces.
This is also not expected to be disabled for release builds because
there are still many dissectors that do not correctly handle strings.
More work is needed to 1) identify them and 2) fix them.
Ping #18317
Do the first ftype-can check in an arithmetic expressions before
evaluating the second term to be sure we do not allow FT_NONE as a
valid LHS ftype.
$ dftest '_ws.ftypes.none + 1 == 2'
Filter: _ws.ftypes.none + 1 == 2
dftest: FT_NONE cannot +.
_ws.ftypes.none + 1 == 2
^~~~~~~~~~~~~~~
The FTREPR_DFILTER format for floating-point numbers
is using an inexact representation so using "apply as
filter" on a floating-point protocol field does not produce a
match, as could be reasonably expected, because we don't
get back the same floating-point number.
Using g_ascii_dtostr() instead produces a string with enough
precision to get back the same machine number with IEEE 754 doubles.
Fixes#16483.
ftype-double.c:89:1: warning: no previous prototype for function 'val_unary_minus'
ftype-double.c:96:1: warning: no previous prototype for function 'val_add'
ftype-double.c:103:1: warning: no previous prototype for function 'val_subtract'
ftype-double.c:110:1: warning: no previous prototype for function 'val_multiply'
ftype-double.c:117:1: warning: no previous prototype for function 'val_divide'
ftype-integer.c:670:1: warning: no previous prototype for function 'uint_bitwise_and'
ftype-integer.c:677:1: warning: no previous prototype for function 'uint_is_zero'
ftype-integer.c:683:1: warning: no previous prototype for function 'uint_is_negative'
ftype-integer.c:689:1: warning: no previous prototype for function 'uint_unary_minus'
ftype-integer.c:704:1: warning: no previous prototype for function 'uint64_bitwise_and'
ftype-integer.c:711:1: warning: no previous prototype for function 'uint64_is_zero'
ftype-integer.c:717:1: warning: no previous prototype for function 'uint64_is_negative'
ftype-integer.c:723:1: warning: no previous prototype for function 'uint64_unary_minus'
ftype-integer.c:738:1: warning: no previous prototype for function 'sint_bitwise_and'
ftype-integer.c:745:1: warning: no previous prototype for function 'sint_is_zero'
ftype-integer.c:751:1: warning: no previous prototype for function 'sint_is_negative'
ftype-integer.c:757:1: warning: no previous prototype for function 'sint_unary_minus
ftype-integer.c:764:1: warning: no previous prototype for function 'sint64_bitwise_and'
ftype-integer.c:771:1: warning: no previous prototype for function 'sint64_is_zero'
ftype-integer.c:777:1: warning: no previous prototype for function 'sint64_is_negative'
ftype-integer.c:783:1: warning: no previous prototype for function 'sint64_unary_minus'
packet-bpv6.c:2182:1: warning: no previous prototype for function 'proto_register_bpv6'
packet-bpv6.c:2766:1: warning: no previous prototype for function 'proto_reg_handoff_bpv6'
packet-bpv7.c:1978:6: warning: no previous prototype for function 'proto_register_bpv7'
packet-bpv7.c:2037:6: warning: no previous prototype for function 'proto_reg_handoff_bpv7'
packet-realtek.c:349:1: warning: no previous prototype for function 'proto_register_realtek'
packet-realtek.c:436:1: warning: no previous prototype for function 'proto_reg_handoff_realtek'
packet-tcpcl.c:2147:1: warning: no previous prototype for function 'proto_register_tcpclv3'
packet-tcpcl.c:2211:1: warning: no previous prototype for function 'proto_reg_handoff_tcpclv3'
Use "True" or "TRUE" instead of "true" and remove case insensivity.
Same for false. This should serve to differentiate booleans a bit
more from protocol names, which should be using lower-case.
Field infos have a length property that was not stored with the
field value so when using a negative index the end was computed
from the captured length of the frame tvbuff, leading to incorrect
results. The documentation in wireshark-filter(5) describes how
this was supposed to work but as far as I can tell it never worked
properly.
We now store the length and use that (when it is different from -1)
to locate the end of the protocol data in the tvbuff. An extra wrinkle
is that sometimes the length is set after the field value is created.
This is the most common case as the majority of protocols have a
variable length and dissection generally proceeds with a TVB subset from
the current layer (with offset zero) through all remaining layers to the
end of the captured length. For that reason we must use an expedient to allow
changing the protocol length of an existing protocol fvalue, whenever
proto_item_set_len() is called.
Fixes#17772.
Instead of saying a leading colon will make any token a literal
value, say it is part of the syntax of bytes arrays. This is
useful to write bytes without a separator, and other potentially
ambiguous formats.
The restriction in meaning to bytes and simple numeric values
should make the rules for handling a leading colon (specifically
ommiting it or not) saner without much loss of functionality.
When retrying fvalue_from_literal() we were leaking the error
message string.
Refactor the code to avoid the retry. This assumes the only
valid use of a leading ':' with a literal is for an IPv6 address.
Bytes with leading ':' are supported but the colon is skipped,
so the parser doesn't see it.
Fixes df0fc8b517.
Add support for display filter binary addition and subtraction.
The grammar is intentionally kept simple for now. The use case
is to add a constant to a protocol field, or (maybe) add two
fields in an expression.
We use signed arithmetic with unsigned numbers, checking for
overflow and casting where necessary to do the conversion.
We could legitimately opt to use traditional modular arithmetic
instead (like C) and if it turns out that that is more useful for
some reason we may want to in the future.
Fixes#15504.
This adds a _ws.ftypes namespace with protocol fields with all
the existing field types.
Currently this is only useful to debug the display filter compiler,
without having to find a real protocol field with the desired type.
Later it may find other uses.
This change implements a unary minus operator.
Filter: tcp.window_size_scalefactor == -tcp.dstport
Instructions:
00000 READ_TREE tcp.window_size_scalefactor -> reg#0
00001 IF_FALSE_GOTO 6
00002 READ_TREE tcp.dstport -> reg#1
00003 IF_FALSE_GOTO 6
00004 MK_MINUS -reg#1 -> reg#2
00005 ANY_EQ reg#0 == reg#2
00006 RETURN
It is supported for integer types, floats and relative time values.
The unsigned integer types are promoted to a 32 bit signed integer.
Unary plus is implemented as a no-op. The plus sign is simply ignored.
Constant arithmetic expressions are computed during compilation.
Overflow with constants is a compile time error. Overflow with
variables is a run time error and silently ignored. Only a debug
message will be printed to the console.
Related to #15504.
Add support for masking of bits. Before the bitwise operator
could only test bits, it did not support clearing bits.
This allows testing if any combination of bits are set/unset
more naturally with a single test. Previously this was only
possible by combining several bitwise predicates.
Bitwise is implemented as a test node, even though it is not.
Maybe the test node should be renamed to something else.
Fixes#17246.
This shared variable hidden behind a macro does not provide any
efficiency gains and just obscures the code. Move the boolean to
the fvalue protocol struct, where it belongs.
For an expression starting with a colon (a literal) try to parse
the value with and without colon. This avoids excluding some
valid representations like the IPv6 address "::1".
A literal value is a value that cannot be interpreted as a
registered protocol. An unparsed value can be a literal or
an identifier (protocol/field) according to context and the
current disambiguation rules.
Strictly literal here is to be understood to mean "numeric
literal, including numeric arrays, but not strings or character
constants".
This relaxes the display filter syntax to accept byte arrays without
separators. An expression such as the following becomes valid:
quic.dcid == b1f0b7cbe0897974
Previously it had to be written as:
quic.dcid == b1:f0:b7:cb:e0:89:79:74
Partially fixes#17818.
Require date/time separators when entering a time value, e,g:
2014-07-04 12:34:56.789+00:00
Separators in the timezone offset are an exception, they are
never mandatory.
This excludes ISO basic format to avoid inputs that could
be entirely numbers indistinguishable from Epoch time, in case
we want to support that in the future.
Add the option to enter a filter with an absolute time
value in UTC. Otherwise the value is interpreted in
local time.
The syntax used is an "UTC" suffix, for example:
frame.time == "Dec 31, 2002 13:55:31.3 UTC"
This also changes the behavior of "Apply Selected as filter".
Fields using a local time display type will use local time
and fields using UTC display type will be applied using UTC.
Fixes#13268.
João Valverde