If we don't have an offset, don't print anything with underline.
Also it can underline filters using macros correctly now.
$ tshark -Y 'ip and ${private_ipv4:ip.sr}' -r /dev/null
tshark: Left side of "==" expression must be a field or function, not "ip.sr".
ip and ip.sr == 192.168.0.0/16 or ip.sr == 172.16.0.0/12 or ip.sr == 10.0.0.0/8
^~~~~
In conversation_filter.h, add a separate log_conv_filter_list. Use it in
register_log_conversation_filter and add conversation_filter_from_log.
It looks like we no longer use find_conversation_filter externally, so
remove it from the API.
We use debian-setup.sh and rpm-setup.sh to build the containers in
https://gitlab.com/wireshark/wireshark-containers/. Make sure they fail
with a nonzero exit status, otherwise we might end up with an invalid
container image.
Make sure OPTIONS is defined in all of the setup scripts that use it.
Add location tracking as a column offset and length from offset
to the scanner. Our input is a single line only so we don't need
to track line offset.
Record that information in the syntax tree. Return the error location
in dfilter_compile(). Use it in dftest to mark the location of the
error in the filter string. Later it would be nice to use the location
in the GUI as well.
$ dftest "ip.proto == aaaaaa and tcp.port == 123"
Filter: ip.proto == aaaaaa and tcp.port == 123
dftest: "aaaaaa" cannot be found among the possible values for ip.proto.
ip.proto == aaaaaa and tcp.port == 123
^~~~~~
Revert to passing a syntax node from the lexical scanner to the grammar
parser. Using a union is not having a discernible advantage and requires
duplicating a lot of properties of syntax nodes.
This removes the limitation of having only two terms in an
arithmetic expression and allows setting the precedence using
curly braces (like any basic calculator).
Our grammar currently does not allow grouping arithmetic expressions
using parenthesis, because boolean expressions and arithmetic
expressions are different and parenthesis are used with the former.
Editcap accepts '-' for stdin or stdout, document that. Also change
an incorrect statement that claims that the '-v' flag writes to
standard output; it writes to standard error.
If we're running in the Logwolf configuration namespace, look for
extcaps in a directory named "extlog". This paves the way for adding
log-specific capture utilities.
InfiniBand and RDMA over Converged Ethernet (RoCE) are handled by the
infiniband dissector. Register DRBD as a dissector for infiniband
payloads.
Not yet implemented:
* Dissection of data payloads. For P_DATA and similar packets, the data
payload is transmitted over multiple packets. Only the first packet
containing the DRBD header is dissected.
* Dissection of the InfiniBand Immediate Data. DRBD uses this for
sequence numbers and for indicating which stream the packet belongs
to.
* Any attempt to associate packets into conversations. This could be
achieved when the connection packets have been captured, but would be
very difficult otherwise.
* An association with infiniband.cm.req.serviceid.dport. When using
RoCE, this is the port that the user specifies for the connection, so
it would be useful to associate it with the DRBD conversation and show
it. Otherwise it is tricky to identify DRBD connections.
RFC 8781 shows in section 4 that the prefix field of the PREF64 option
header is always 96 bits (or 12 bytes), regardless of the prefix length
code that only specifies which parts of the prefix are significant. The
option itself thus always has a fixed length. Even if they are not used
in the significant part of the prefix itself, the unused bits are still
part of the prefix field of the PREF64 option and the offset must be
adapted accordingly.
The previous implementation would fail to correctly parse any PREF64
option with a PLC other than 0 (i.e. the full 96 bits) due to the unused
remaining bits in the option not being consumed.
Closes#18033.
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.
João Valverde