As stated in 3GPP 26.445 chapter A.2.2.1.4.2, RTP padding must be taken
into account to discrimate between Header-Full format and Compact format
Closes#18498
This an action frame to update the EMLSR / EMLMR mode.
This adds partial support for this frame.
It is fairly hairy to parse it because of its variable format, so for
now, just parse the EMLSR part and leave the EMLMR part for later.
According to TS 26.101, AMR_SID payload is 39 bits.
Hence, (39+7)/8 = 5, rounding to octet boundaries.
This fixes incorrect dissecting of Osmux frames containing AMR_SID
payloads.
Add a tlsinfo struct that is similar to tcpinfo, and carries
the sequence number (within the TLS stream) and the end of
stream notification (from the TCP FIN or close_notify alerts)
in addition to the session app handle pointer already used
by TLS heuristic dissectors.
Have HTTP use the end of stream notification in order to
handle DESEGMENT_UNTIL_FIN the same way it does when HTTP
is directly over TCP. Also have HTTP use the sequence number
in order to reduce chunked processing from O(N^2) to O(N)
similar to done over TCP.
Update all the TLS heuristic dissectors that set the app
handle to use the new structure.
Note the workaround for the issue #15159 - the TLS dissector
has to report to the TCP dissector that desegmentation at FIN
is required, so that the TCP dissector will know to call the
TLS dissector at FIN. However, the TLS dissector does not request
that the TCP dissector resend bytes belonging to records that
TLS has already desegmented (and decrypted, if possible), to
avoid decrypting twice (and upsetting the decoder state.)
This can mean the TCP dissector calling the TLS dissector to
desegment at FIN with a zero byte payload. In such as case, the
TLS dissector artificially returns "1" byte dissected to avoid
indicating rejecting the payload and having the TLS (and subdissector)
layers removed. (TCP ignores the value returned when desegmenting
at FIN.)
Fix#9154. Fix#14382.
The host, request method, request URI, and response code are
information that are local to a request/response pair. Storing
them in the conversation data struct means that we only have access
to one set of values at any one point.
Currently they are updated every time a packet is dissected,
which is fine for sequential processing but causes unexpected
behavior when scrolling the window upwards, going directly
to a packet, or filtering, among other out of order behavior.
Store the values in the per packet data, and create the
file scoped data only on the first pass. The conversation
level data will have access to the final http_req_res_t
struct, which is useful for connections that Upgrade to a
different dissector.
Also, when a response code is in the Informational 1xx category,
that means it is an interim response and the next response could
be for the same request. (This affects 100 Continue, 103 Early
Hints, etc.)
Fix#16753.
Add the name, type, and values of field tables and arrays as
fields under the FT_NONE header. This makes them filterable
and show up in JSON export.
Fix#18385
packet-ieee80211.c:10060 proto_tree_add_item called for hf_ieee80211_hs20_icons_avail_len - item type is FT_UINT8 but call has len 2
packet-ieee80211.c:11869 proto_tree_add_item called for hf_ieee80211_ff_key_data_length - item type is FT_UINT8 but call has len 2
packet-ieee80211.c:21328 proto_tree_add_item called for hf_ieee80211_s1g_short_beacon_interval - item type is FT_UINT8 but call has len 2
packet-ieee80211.c:32379 proto_tree_add_item called for hf_ieee80211_pentapartial_timestamp - item type is FT_UINT8 but call has len 5
packet-ieee80211.c:32932 proto_tree_add_item called for hf_ieee80211_pv1_cnt_bat_bitmap - item type is FT_UINT16 but call has len 4
packet-ieee80211.c filter= wlan.he_ndp.sta_info.ru_start - mask has odd number of digits 0x3F800 expected max for FT_UINT32 is 8
packet-ieee80211.c filter= wlan.he_ndp.sta_info.ru_end - mask has odd number of digits 0x1FC0000 expected max for FT_UINT32 is 8
For a string, add the value from the packet normally so that the
value is filterable, shows up in JSON, etc. Prepend the tag
description to the item so the formatting is displayed in the
tree with the name like it has been.
Use the information gained from conversation tracking to infer
well-known names. Show well-known names as addresses to improve the
readability of a D-Bus capture.
Add the method name to response frames, like Method Return and Error.
The name is not included in the frame itself, but can be inferred with
conversation tracking.
Add generated fields with the value from the request. D-Bus response
frames don't include fields like "member", i.e. the method name. By
adding generated fields it's easier to filter method calls and its
method return by name.
The poll and precision fields in timing NTP messages are signed
integers.
Different NTP implementations have different minimum and maximum polling
intervals. Some can be configured even with negative values for
sub-second intervals (e.g. down to -7 for 1/128th of a second).
NTP clocks on modern systems and hardware typically have
a sub-microsecond precision.
Print all poll values. Add the raw precision and change the resolution
of the printed value to nanoseconds.
The fragment functions will work with a zero length fragment,
which might happen if a record length is zero in a malformed
packet and a reassembly is in progress. It is not by itself
a fatal error (and could actually work, even though
non-compliant.) There is already a tls.record.length.invalid
expert info added by ssl_check_record_length for this case.
Related to #17890.
1. Fix the bug that the timestamp of google.protobuf.Timestamp message
type does not displayed while pbf_as_hf (Dissect Protobuf fields as
Wireshark fields) is FALSE.
2. Add the use_utc preference for displaying google.protobuf.Timestamp
in UTC or local zone format.
Add a dissector table "btcommon.eir_ad.entry.uuid_16", which behaves the same
way as the hard-coded GAEN (Google/Apple Exposure Notification) dissector does
today -- the table key is the 16-bit UUID
(https://www.bluetooth.com/specifications/assigned-numbers/), and the dissector
is given the corresponding service data.
A device is not allowed to start a new control procedure if it
has already responded to a peer procedure.
The detection of a response being present did not take into account
that some procedures do not have a response.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
According to 3GPP TS 44.018 section 10.5.2.20, the Measurement Results
is a type 3 (TV) information element with 17 (1 + 16) octets length.
The respective dissection function is called as follows:
ELEM_MAND_V(GSM_A_PDU_TYPE_RR, DE_RR_MEAS_RES, ...)
elem_v(tvb, tree, pinfo, GSM_A_PDU_TYPE_RR, DE_RR_MEAS_RES, ...)
de_rr_meas_res(tvb, subtree, pinfo, curr_offset, -1, ...)
^^^
len
Note that elem_v() passes -1 as the len argument to de_rr_meas_res().
The later returns -1 casted to guint, and this is indeed wrong.
Moreover, the 'len' argument is marked as unused (_U_).
This bug creates a false impression that the Measurement Results IE
occupies more octets than it actually does when it's encapsulated
into some other protocol, e.g. A-bis/RSL.
Let's return value 16, which is known from the specs.
This way we can also use this function for checking padding in
the Measurement Results IE, which uses 0x00 as padding pattern.
Drop the '_csn' part because it's not CSN.1 specific anymore.
Martin Mathieson
Pau Espin
Vadim Yanitskiy