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
Instead of using the abstract type "<RAW>", which might be confusing,
show FT_BYTES, but display the representation with the "@" operator,
so it's not even more confusing in error messages why a field might
flip-flop types.
Refactor the field tostr() function and some other clean ups.
Before:
```
Filter: _ws.ftypes.string ==${@frame.len}
dftest: _ws.ftypes.string and frame.len <RAW> are not of compatible types.
_ws.ftypes.string ==${@frame.len}
^~~~~~~~~
```
After:
```
Filter: _ws.ftypes.string ==${@frame.len}
dftest: _ws.ftypes.string <FT_STRING> and @frame.len <FT_BYTES> are not of compatible types.
_ws.ftypes.string ==${@frame.len}
^~~~~~~~~
```
Extends raw adressing syntax to wok with references. The syntax
is
@field1 == ${@field2}
This requires replicating the logic to load field references, but
using raw values instead. We use separate hash tables for that,
namely "references" vs "raw_references".
This adds new syntax to read a field from the tree as bytes, instead
of the actual type. This is a useful extension for example to match
matformed strings that contain unicode replacement characters. In
this case it is not possible to match the raw value of the malformed
string field. This extension fills this need and is generic enough
that it should be useful in many other situations.
The syntax used is to prefix the field name with "@". The following
artificial example tests if the HTTP user agent contains a particular
invalid UTF-8 sequence:
@http.user_agent == "Mozill\xAA"
Where simply using "http.user_agent" won't work because the invalid byte
sequence will have been replaced with U+FFFD.
Considering the following programs:
$ dftest '_ws.ftypes.string == "ABC"'
Filter: _ws.ftypes.string == "ABC"
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.string <FT_STRING>)
1 FVALUE("ABC" <FT_STRING>)
Instructions:
00000 READ_TREE _ws.ftypes.string <FT_STRING> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == "ABC" <FT_STRING>
00003 RETURN
$ dftest '@_ws.ftypes.string == "ABC"'
Filter: @_ws.ftypes.string == "ABC"
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.string <RAW>)
1 FVALUE(41:42:43 <FT_BYTES>)
Instructions:
00000 READ_TREE @_ws.ftypes.string <FT_BYTES> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == 41:42:43 <FT_BYTES>
00003 RETURN
In the second case the field has a "raw" type, that equates directly to
FT_BYTES, and the field value is read from the protocol raw data.
When the classic profile has been cloned, and it contains
coloring rules, that are no longer valid or their syntax is
wrong, the export of single profiles will fail.
The reason for that is still being investigated. It seems
there might be an issue with selecting the right coloringfilter
to be selected.
This change only fixes the coloringrules file and the
index is selected from the base model instead
Previously, Wireshark was sorting all packets in a capture,
regardless whether they were actually visible or not. If you
are working with large PCAPs & filters, this is a MASSIVE
performance drag. Therefore, this commit changes this
by only sorting the visible packets which boosts the
sorting performance in filtered views massively.
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.
Generate filter expressions for columns with multiple occurrences
by using the membership operator (which is semantically OR).
It's not clear if this approach makes more sense than AND;
there's use cases for both.
Don't do this for multifield custom columns, since we don't know
which values were found by which field. That takes changing
the column logic in several places.
Ping #18001
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.
Since cbd3c447 ("ftypes: Add FT_UINT_STRING to IS_FT_STRING() macro")
proto_tree_add_string() accepts FT_UINT_STRING, but the API check still
fails. Update the API check to reflect that change.
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.
Normally, 'control' and 'otherbss' flags are set when
using monitor mode, but certain Wi-Fi drivers (e.g. MT7921)
need to explicitly have these flags set in order to capture
control frames.
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.
John Thacker
Vadim Yanitskiy