Allow matching against 64-bit extended value strings the same
way as other value strings.
The IAX2 sample capture on the Wiki is a good test of this. Previously
the matches operator would never match, and comparison operators we not
allowed.
Before:
$ ./run/dftest -s 'iax2.voice.codec == "GSM compression"'
Filter:
iax2.voice.codec == "GSM compression"
Error: "GSM compression" cannot be found among the possible values for iax2.voice.codec.
iax2.voice.codec == "GSM compression"
^~~~~~~~~~~~~~~~~
After:
$ ./run/dftest -s 'iax2.voice.codec == "GSM compression"'
Filter:
iax2.voice.codec == "GSM compression"
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(iax2.voice.codec <FT_UINT64>)
1 FVALUE(2 <FT_UINT64>)
Instructions:
0000 READ_TREE iax2.voice.codec -> R0
0001 IF_FALSE_GOTO 3
0002 ANY_EQ R0 == 2
0003 RETURN
Rework the changes from 428f222853
a little bit to restore the ability to start a capture from
the extcap options dialog.
When the the dialog is opened for configuration, present both the
Save and the Start button. Continue to only have Start when the
dialog was spawned because the user wanted to start a capture
but a mandatory parameter was not configured.
Use the default QDialogButtonBox "Discard/Close without Saving"
button when closing the dialog without saving the user input
for new preferences.
Fix#19199
Reduce false positives of the CLTP on UDP dissector (RFC 1240)
by looking at the parameters as well and also ruling out length
indicator zero.
See https://ask.wireshark.org/question/31455/i-see-a-malformed-packet-in-wireshark-from-a-google-ip-address-on-port-2400-using-r-goose-protocol-what-could-this-be/
RFC 1240 was rendered Historic by RFC 2556, which noted that
"at this time there do not seem to be any implementations" and
recommended TPKT (ISO on TCP) instead.
However, R-GOOSE does use RFC 1240. In practice, it seems like
R-GOOSE uses the IANA registered port for ISO-TSAP, 102, just like
TPKT does on TCP. Perhaps we should register the dissector to that
port instead of a heuristic dissector if someone can confirm that.
Move the dissector from goose to ositp. This doesn't cause any
preference issues because heuristic dissectors are saved in the
preference file by name and the name won't change.
The documentation, both man page and help, claims that text2pcap
automatically sets the encapsulation to WIRESHARK_UPPER_PDU if
-P is given. Make the behavior match the documentation.
The TPNCP dissector depends upon a resource file, tpncp.dat, being loaded
during initialization. If a non-default tpncp.dat was used, the TPNCP
dissector could potentially perform some operations beyond the bounds of a
fixed-size array while loading tpncp.dat.
If a non-default tpncp.dat was used and an attempt was made to dissect
malformed TPNCP traffic, the TPNCP dissector could potentially perform a read
beyond the end of an array.
This change adds explicit bounds-checks to eliminate these possible OOB
accesses.
There is zero chance of this being triggered in a default unmodified
installation of Wireshark: Loading of the tpncp.dat file is conditional on a
preference setting which defaults to FALSE, and even if it is configured to
TRUE, the included tpncp.dat does not trigger either of these OOB operations.
It still seems worthwhile to make the parser and dissector generally more
robust.
Fix
```
/builds/wireshark/wireshark/epan/dissectors/file-jpeg.c:773:1: warning: function 'process_tiff_ifd_chain' is within a recursive call chain [misc-no-recursion]
773 | process_tiff_ifd_chain(proto_tree *tree, tvbuff_t *tvb, packet_info *pinfo,
| ^
/builds/wireshark/wireshark/epan/dissectors/file-jpeg.c:773:1: note: example recursive call chain, starting from function 'process_tiff_ifd_chain'
/builds/wireshark/wireshark/epan/dissectors/file-jpeg.c:896:37: note: Frame #1: function 'process_tiff_ifd_chain' calls function 'process_tiff_ifd_chain' here:
896 | process_tiff_ifd_chain(tree, tvb, pinfo, encoding,
| ^
/builds/wireshark/wireshark/epan/dissectors/file-jpeg.c:896:37: note: ... which was the starting point of the recursive call chain; there may be other cycles
```
- Move all basic dissect_thrift_t_<type> implementations into
dissect_thrift_raw_<type> that takes an additional dissector_t
parameter.
- All dissect_thrift_t_<type> just calls dissect_thrift_raw_<type>
with a NULL raw dissector.
- When the dissector_t parameter is set, create a sub-tvbuff_t pointing
to the raw content of the simple type (integral or binary).
- There are 2 specific cases within the TCompactProtocol part:
1. For booleans, the sub-dissector is responsible for using only the
least significant bit as the boolean value. The most obvious use
of the boolean raw sub-dissector is the use of a true_false_string.
2. For varint, we manufacture a tvbuff_t containing the big-endian
value of the right size to be the same as TBinaryProtocol.
- Allow the raw sub-dissector to push the responsibility back to the
generic dissector using thrift_opt_t.use_std_dissector = TRUE.
A common use case for that is a specific dissection for some values
only in a key/value map (configuration keys).
- Add a public dissect_thrift_t_raw_data() function that takes a type
for dispatch as well as the dissector_t.
Fix
```
wireshark/epan/dissectors/packet-isis-lsp.c:3431:1: warning: function 'dissect_sub_clv_tlv_22_22_23_141_222_223' is within a recursive call chain [misc-no-recursion]
3431 | dissect_sub_clv_tlv_22_22_23_141_222_223(tvbuff_t *tvb, packet_info* pinfo, proto_tree *tree,
| ^
wireshark/epan/dissectors/packet-isis-lsp.c:3431:1: note: example recursive call chain, starting from function 'dissect_sub_clv_tlv_22_22_23_141_222_223'
wireshark/epan/dissectors/packet-isis-lsp.c:3541:21: note: Frame #1: function 'dissect_sub_clv_tlv_22_22_23_141_222_223' calls function 'dissect_sub_clv_tlv_22_22_23_141_222_223' here:
3541 | dissect_sub_clv_tlv_22_22_23_141_222_223(tvb, pinfo, subtree, local_offset, local_len);
| ^
wireshark/epan/dissectors/packet-isis-lsp.c:3541:21: note: ... which was the starting point of the recursive call chain; there may be other cycles
```
Add Clang-Tidy suppressions as well.
If writing a separate extcap preferences file fails, always write the
main preference file.
If there's a directory of the same name as a module, silently ignore it.
Followup to !14436
If someone manually puts a directory, or a FIFO, or something
else (block device?) in a configuration directory with the same
name as a preference file, don't try to copy it and just silently
ignore it.
Add an initial Clang-Tidy configuration file which checks for recursion
and various clang analyzer issues.
Run Clang-Tidy in the "Clang + Code Checks" merge request job.
Add NOLINT suppressions where needed in wsutil, epan, and lemon.
Continue to write the format-based hidden preference for now.
Read both preferences; if the index-based preference is read, use it.
If not, fall back to the format-based preference.
Followup to 41930060b0
We already do so for DL Data blocks, and it's useful as well for DL
Control blocks, in order to easily follow the communication between the
PCU and the scheduled TBF of each MS.
The matches operator implicitly converts non-stringlike fields
that have value strings to their value string value. (This is
not the same as the string representation of the number, which
applying the string function first would do, but it usually less
useful and worse performance than using numeric comparisons.)
However, FT_FRAMENUM fields have a hfinfo->strings but it is not
strings used for conversion, it is an overload with the special
ft_framenum_type_t, so don't convert.
This prevents a segmentation fault if expressions with
expressions like 'gtp.response_in ~ "test"'
Do not change the preference pointer inside the Extcap Options
Dialog. That changes the real preference value, which disturbs
the check inside prefs_store_ext_multiple that storeValues() calls
for whether a pref has changed or not. Since the prefs are already
changed to their new value, we won't realize that we need to write
out a new preference file.
The other changes in #18487 are sufficent to fix the problem
identified there (though it's a bit unclear what "required" means
in combination with a default, and whether we have to send the
default value for the required parameter or can omit it.)
If the button says "Save", then save the preferences regardless
of what the "extcap Save on Start" preference says.
Fix#19639. Related to #18487
If the capture.no_extcap preference is set, really don't load the
extcap interfaces. Previously, the extcap interfaces were loaded
before the preference was read, because otherwise the extcap
preferences wouldn't be registered and properly read out of the
configuration file.
Wait until after that preference is read to register the
extcap preferences and then re-read just the extcap module
preferences from the configuration files. Make sure to check
other times when the preference may be changed, such as
switching profiles.
Write extcap prefs to a separate file so that they don't get lost
if the extcap interfaces aren't loaded and the prefs are then
written out. Continue writing them to the main file for backwards
compability.
Related to #15295. Cuts ~100 ms off the loading time of Wireshark
in a normal situation if the capture.no_extcap preference is set,
more if an extcap has some kind of issue that makes it take a long
time to load.
Anders Broman
Pau Espin