Changes the function calling convention to pass the first register
number plus the number of registers after that sequentially. This
allows function with any number of arguments. Functions can still
only return one value.
Adds max() and min() function to select the maximum/minimum value
from any number of arguments, all of the same type. The functions
accept literals too. The return type is the same as the first argument
(cannot be a literal).
Remove unused header definitions in packet-falco-bridge.h and move the
remaining content to packet-falco-bridge.c and conversation-macros.h.
Explicitly set our header files in CMakeLists.txt.
Move the assumption for WHOIS responses to UTF-8 (which is backwards
compatible with ASCII), and add an expert info regarding that
assumption. There is no indication for encoding in the protocol.
Using Show Packet Bytes is sufficient for most purposes, but someone
could add a preference if desired.
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.
João Valverde