ISO C Std § 6.7.2, 5: "for bit-fields, it is implementation-defined
whether the specifier int designates the same type as signed int or the
same type as unsigned int." (See also the note in § 6.7.2.1 and ISO C
Std Appendix J.3.9.)
A gboolean is a typedef'd gint. Therefore, many implementations,
including gcc and clang, treat a gboolean bitfield of width 1 as
signed, meaning that it has two possible values: 0 and -1, any time
the integer promotions occur (which is all the time.) Constructs like this:
dgram_info->from_server = TRUE;
if (dgram_info->from_server == TRUE) ws_warning("True");
will not work as expected, though gcc (but not clang) will give an
error:
/home/johnthacker/wireshark/epan/dissectors/packet-quic.c:3457:37: error: comparison is always false due to limited range of data type [-Werror=type-limits]
3457 | if (dgram_info->from_server == TRUE)
|
proto_tree_add_debug_text(quic_tree, "Connection: %d %p from_server:%d", pinfo->num, dgram_info->conn, dgram_info->from_server);
Connection: 1 0x7fc4b47f2be0 from_server:0
Connection: 2 0x7fc4b47f2be0 from_server:-1
Connection: 3 0x7fc4b47f2be0 from_server:0
Connection: 4 0x7fc4b47f2be0 from_server:-1
At worst this can cause buffer overruns.
If a bitfield is desired, to guarantee expected behavior the standard
_Bool/bool should be used instead.
prefs_find_module() looks up a module by module name, which is
the same as the protocol filter name, case-insensitively.
dissector_table_get_dissector_handle() looks up a dissector handle
in the table by the protocol short name (which is the module _title_)
deprecated_port_pref() used the same string for both lookups.
For some protocols this worked, because the short name is the same
as the filter name only with different capitalization. For others,
it either wouldn't find the module to add to the migrated preference,
or wouldn't find the dissector handle in order to set Decode As
properly.
Fix this, by using the module title for the second lookup, and
changing all the module_name values to be correct. For good
measure, change all the module names that happened to work because
they're differently-cased versions of the filter name in order
to avoid confusion when new entries are added.
The "Last updated" footer time is the last modified time of the source
file. We could make it reproducible using something like
git-restore-mtime, but it's easier (and IMHO less ugly) to just remove
the footer.
Q.713 s1.5 states optional parameters may be received in any
order. Q.714 s1.1.42 states unrecognized parameters within a
message are ignored.
This patch fixes Wireshark's compliance with the specs and allows
the segmentation parameter to occur anywhere with the options
SCCP places a limit of 255 bytes on DATA parameters, and
segments data beyond that. Some tracing tools will externally
reassemble data, writing a single message with an indicated
length of 255 octets but with a longer payload. Allow the pref
setting introduced in 086feb2f09
to work for all message containing DATA, such as XUDT messages.
(Note that some tools leave the optional SEGMENTED parameter
in when externally reassembling, and some do not.) Add an
expert info to hint to the user when the setting might be
worth changing. (Perhaps it should be default to TRUE?)
Fix#10515
Use the timer polling approach on Windows. GLib timer callbacks execute
in main thread. Remove useless mutex as there is no point in protecting
resources if only can thread can access the resources. Simply wait on
capture child handle instead of periodically checking process state.
On Unix systems, register the pipe fd for polling inside GLib mainloop.
Do the first ftype-can check in an arithmetic expressions before
evaluating the second term to be sure we do not allow FT_NONE as a
valid LHS ftype.
$ dftest '_ws.ftypes.none + 1 == 2'
Filter: _ws.ftypes.none + 1 == 2
dftest: FT_NONE cannot +.
_ws.ftypes.none + 1 == 2
^~~~~~~~~~~~~~~
1. Passing header name/value map to sub-dissector in packet-http.c.
Headers can also be used by dissectors other than grpc in the future.
2. Try to get the grpc-encoding header value in packet-grpc.c.
This header contains decompression algorithm.
We are not bundling the Lua source code but the library
is an important part of Wireshark and just as deserving
(if not more) of a mention as other Lua dependencies that
are already featured as acknowledgements.
Using the addresses and ports to retrieve the QUIC connection
has issues with connection migration. We deal with that in
the QUIC dissector and store that information in proto data.
Use that proto data for generating the follow filter from a
selected packet. This makes it more robust to connection migration
and cases where different QUIC connections reuse the same UDP
5-tuple.
1. Block FP is used in both U plane I.Q. samples and C plane beamforming
weight decompression.
2. excluded digital power scaling(DPS) out of BFP decompression, i.e. (1<<15)
bits shift, because DPS is applied only U plane.
3. added digital power scaling to be called from U plane I.Q. samples
calculation.
4. improved U plane I.Q. samples calculation similar logic used in C
plane bfw calculation.
5. improved U plane I.Q. samples index start from '0'.
reference: O-RAN WG4.CUS.0 v.09.00.
8.1.2 and 8.1.3 for clarification, digital power scaling applied only U
plane.
annex A.1.2 and A.1.3 for clarification, digital power scaling not
included in Block FP.
annex D for I.Q. smples index
As the RULE_LAUNCH_COMPILE documentation says,
"Note: This property is intended for internal use by ctest(1). Projects
and developers should use the <LANG>_COMPILER_LAUNCHER target properties
or the associated CMAKE_<LANG>_COMPILER_LAUNCHER variables instead."
The endpoint elements pinfo->conv_endpoint and pinfo->conv_elements
cause find_or_create_conversation (via find_conversation_pinfo) to
look for conversations based on those endpoints. It should also
make it create conversations based on those endpoints, so that
subsequent calls find the same conversation it just created instead
of repeatedly creating new ones.
Implement out of order buffering and desegmentation for QUIC
CRYPTO frames. Particularly useful for Chrome's "Chaos Protection"
that intentionally introduces them, but handles out of order
CRYPTO frames in different UDP payloads as well. (Buffering
packets at a higher encryption level until the out of order
lower level frames have arrived is a different issue.)
Adds a preference, which defaults to on since if there is
out of order, it's not very useful to turn it off.
Fix#17732. Fix#18215.
Tomasz Moń