Instead of using a heuristic to decide whether the form ${...} is
a macro or not, try to resolve the name to a registered protocol
field and use that instead.
This increases somewhat the surface for clobbering existing macro
names with new field registrations but we'll cross that bridge when
we get to it.
Rejecting protocol field types reduces this probability again but it
may not be intuitive to the user trying to mistakenly use a reference
to a protocol why it is parsed as a macro. The reasons for rejecting
FT_PROTOCOL types as not interesting field references are not
very strong but it seems reasonable.
$ dftest 'frame.number != ${frame.number}'
Filter: frame.number != ${frame.number}
Instructions:
00000 READ_TREE frame.number -> reg#0
00001 IF_FALSE_GOTO 5
00002 READ_REFERENCE ${frame.number} -> reg#1
00003 IF_FALSE_GOTO 5
00004 ALL_NE reg#0 != reg#1
00005 RETURN
$ dftest 'frame != ${frame}'
dftest: macro 'frame' does not exist
Add a selected frame option that does pretty much what the name
indicates.
This is not meaningful in the CLI but is useful to simulate the
selected frame action in the GUI for unit testing purposes. The
option is not documented for that reason.
A selected frame is used in display filters with field references.
$ tshark -r ../test/captures/dhcp.pcap
1 0.000000 0.0.0.0 → 255.255.255.255 DHCP 314 DHCP Discover - Transaction ID 0x3d1d
2 0.000295 192.168.0.1 → 192.168.0.10 DHCP 342 DHCP Offer - Transaction ID 0x3d1d
3 0.070031 0.0.0.0 → 255.255.255.255 DHCP 314 DHCP Request - Transaction ID 0x3d1e
4 0.070345 192.168.0.1 → 192.168.0.10 DHCP 342 DHCP ACK - Transaction ID 0x3d1e
$ tshark --selected-frame=2 -2 -Y 'frame.number <= ${frame.number}' -r ../test/captures/dhcp.pcap
1 0.000000 0.0.0.0 → 255.255.255.255 DHCP 314 DHCP Discover - Transaction ID 0x3d1d
2 0.000295 192.168.0.1 → 192.168.0.10 DHCP 342 DHCP Offer - Transaction ID 0x3d1d
The same hierarchy of protocols can appear multiple times in a frame,
for example if there are multiple PDUs for a protocol that begin in
that frame. Keep track of the last frame where we incremented our
stat node and use that to only increment it once per frame.
Add a "total number of PDUs with this hierarchy" statistic and
display it as a new final column in the GUI. Update the User Guide.
In the purpose of doing this, get rid of temporary variables and
increment the ph_stats_t members directly, since we pass that
into our functions already, and thus have access to the current
packet count.
Fix#17553. Fix#18034. Fix#12565.
The WHOIS and finger dissectors wait to dissect at FIN, but they
need to actually dissect at FIN (or at reassembled out of order
segments after FIN) on the first pass instead of returning without
dissecting.
Only add data reassembled at FIN to the tree if it was actually
reassembled at the FIN frame; if it was reassembled in the first pass
at a later frame due to out of order segments, it will be added there.
In addition to fixing first pass dissection, this also fixes the
case where the FIN segment is the first segment with data. Fix#18037.
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.
Moshe Kaplan