The configuration of the build machine is not part of our public
API. 'config.h' must not be installed with system headers,
otherwise it generates all sorts of collisions and generally makes
life unpleasant.
Use FT_ETHER for the MAC address, unless the scrambling bits are set,
in which case use a FT_BYTES field. Don't put the address in a separate
tvb, so the bytes it is extracted from can be highlighted. Don't decode
the payload if the payload scrambling bits are set. Add value_strings and
expert infos.
When building with GCC 10.2.0 and optimization level 3 some new
warnings turn up. Fix them.
./epan/crypt/dot11decrypt_util.c: In function ‘dot11decrypt_derive_pmk_r0’:
../epan/crypt/dot11decrypt_util.c:308:5: error: ‘sha256_res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
308 | memcpy(pmk_r0_name, sha256_res, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../epan/crypt/dot11decrypt_util.c: In function ‘dot11decrypt_derive_pmk_r1’:
../epan/crypt/dot11decrypt_util.c:357:5: error: ‘sha256_res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
357 | memcpy(pmk_r1_name, sha256_res, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../wiretap/wtap_opttypes.c: In function ‘wtap_block_add_if_filter_option’:
../wiretap/wtap_opttypes.c:782:12: error: ‘*((void *)&filter_dest+8)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
782 | return filter_dest;
| ^~~~~~~~~~~
../wiretap/wtap_opttypes.c: In function ‘wtap_block_set_if_filter_option_value’:
../wiretap/wtap_opttypes.c:782:12: error: ‘*((void *)&filter_dest+8)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
782 | return filter_dest;
| ^~~~~~~~~~~
From tools/check_typed_item_calls.py:
epan/dissectors/packet-mpeg-dsmcc.c:1212 proto_tree_add_item called for hf_dsmcc_dii_private_data_length - item type is FT_UINT8 but call has len 2
- add an option to decrypt even if not strictly in-sequence
In the top-level .editorconfig, note that we don't use CMake's standard
indentation.
Remove ascendtext.[ch] from wiretap/.editorconfig since it's no longer
needed.
DVB-DATA Multiprotocol Encapsulation (MPE) has the table id 0x3E, which
is conformant to DSM-CC sections with private data, and is by far the
most common "private" implementation. Only register MPE as the default
subdissector for 0x3E, don't register DSM-CC as well. (The order of
registration means that MPE is already the current default, but this
is not reliable.)
Support Decode As for the table ids so that DSM-CC can be used instead if
someone really wants that, and so that some other user private dissector
plugin (on 0x3E or any other user private table_id) can be used.
Switch ui/clopts_common.c, ui/filter_files.[ch], and ui/summary.[ch] to
4 space indentation. This brings them in line with all of the other
files in that directory and with ui/qt.
Fix the modelines in ui/qt/models/filter_list_model.cpp.
I believe this was the original intention, to use these API restricitons
with dissectors only (not that I necessarily agree with that policy either),
and through copy-paste and lack of clear guidelines it spread to other
parts of the build.
Rename the checkAPI groups to make it very clear that this is dissector-only.
This doesn't mean, of course, that good programming practices shouldn't be
followed everywhere. In particular assertions need to be used properly.
Don't use them to catch runtime errors or validate input data.
This commit will be followed by another removing the various ugly hacks
people have been using to get around the checkAPI hammer.
This commit should be a proper fix for the regression reported in #17250
(7fd71536 is a simple workaround). Such regression has been introduced by
b287e716 while fixing the infinite loop reported in #16897.
b287e716, while fixing the infinite loop, broke the decoding of perfectly
valid tags not yet supported by Wireshark.
AFAIK, the root cause of the infinite loop is the overflow of the `offset`
variable. Therefore checking for this overflow should be sufficient to avoid
the loop.
Note that we already check for sensible values for the 'tag_len' variable;
we should update `total_tag_len` accordingly.
Some words about testing: other than correctly handling unknown but valid
tags, it is important that this commit doesn't reintroduce the infinite
loop bug.
Fortunately #16897 provided a POC trace. Unfortunately, if you revert
b287e716, this POC doesn't work anymore in master-3.4 and master branches,
but it still triggers the infinite loop in master-3.2 branch.
Therefore I have been able to manually check that this MR + the
overflow check is enough to avoid the infinite loop bug, at least in master-3.2.
Some traffic with unknown but valid tags is available in e2ee14ae03.
Commit 73d793788c removed ws_printf.h from
column-utils.c, but left no prototype for snprintf, causing a build failure on
my Debian testing host. Let's #include <stdio.h> here.
1) G_GUINT16_FORMAT produces warnings about mismatched format string
formats and arguments if you use it with a 32-bit value.
2) There's no reason to format into a string buffer and then use
col_append_lstr(); col_append_fstr() suffices. (In col_append_ports(),
the formatting is done with col_snprint_port(), which attempts to
resolve the port number to a name, but we don't do that here, we just
format it as a number.)
Since fe94133f0d ws_snprintf()
and ws_vsnprintf() don't actually do anything anymore.
The return value of ws_[v]snprintf was discarded before,
now it too conforms to C99.
COContainerContent dissects PDInterfaceMrpDataAdjust and
PDInterfaceMrpDataAdjust dissects remaining COContainerContent
because of offset problem. Offset problem is fixed.
Use tvb_captured_length() instead of returning integer offset.
Otherwise, the packet is marked as malformed and the rest of the
packet is not processed.
Don't handle request/response tracking when pinfo->flags.in_error_pkt
is set (DNS packets contained within ICMP/ICMPv6 error packets).
Fix: wireshark/wireshark#15036
Have it return WTAP_FILE_TYPE_SUBTYPE_UNKNOWN, rather than an
undecorated -1, if the hash table lookup fails.
Check for that as a return value, and pop up a "file an issue" dialog if
WTAP_FILE_TYPE_SUBTYPE_UNKNOWN is returned.
This should squelch Coverity CID 1473325; the error Coverity reports is
bogus, as negative file type/subtype values are check for before we try
to use them as suffixes, but this should catch the "this should not
happen" case that caused the error to pop up.
Dissect client hello SRP extension to extract SRP username.
Decryption is already supported by SSLKEYLOGFILE's client random
and pre-master secret. Add ciphers to decryptable cipher list
so that a decoder is created.
This merge request adds:
* Decoding of ProtocolID and PPID in Component Status Protocol dissector.
* Moved SCTP PPID list from SCTP dissector into separate file sctpppids.c,
due to reuse in Component Status Protocol dissector.
* Export of sctpppid_val_ext containing the PPID list.
Some DVB-CI messages contain a file that can be dissected by the mime-encap
dissector. mime-encap adds itself to the protocol column. We already set a
fence, but things still look messy:
DVB-CIMIME_FILE
This patch adds ", " before the fence and "Data" afterwards. If mime-encap
is enabled, it'll overwrite the Data with its protocol name
DVB-CI, MIME_FILE
If mime-encap is disabled, the embedded file will be handled by the data
dissector, who doesn't touch the protocol column. So we keep
DVB-CI, Data
Note that we use EditorConfig in the WSDG and README.developer, and that
you should make sure your editor uses it. Recommend 4 space indentation
more strongly. Ping #17253.
Reorder and reword the coding style sections of each document while
we're here.
from the earlier version C37.237-2011. The previous version of this
standard, IEEE Std C37.238-2011, separated grandmaster time inaccuracy
and what was then called NetworkTimeInaccuracy into two fields. The
first, grandmasterTimeInaccuracy, was located immediately before
totalTimeInaccuracy in this version (now a reserved field). The second,
networkTimeInaccuracy, was located where totalTimeInaccuracy is now
found.
Those are used by more than one file type, so we should provide a block
type for them. (We don't *currently* use that block type, or the packet
block type, but this makes them available for future use.)
João Valverde