When desegmenting TCP, we only want to call subdissectors when processing
the last segment. With encapsulation, TCP might appear at more than one
layer in the frame, so check that the layer number of the last segment
matches the current layer number too, just like in
process_reassembled_data()
When there is more than one TSP in a frame, the fragment at the
end of one TSP and the first fragment in the next have the same
layer number as well as frame number. So use other information
about whether we have the last fragment to avoid calling subdissectors
extra times (which can interfere with retrieving the packet analysis
proto data on the subsequent passes.)
Just have a single switch for all packetlogger packet types, with a
routine doing the common code for all packets treated as Bluetooth H1
interface packets.
This means that unknown types are never handed off to the Bluetooth H1
interface dissector; it is probably best not to hand it to that
dissector, as the packet might not be a Bluetooth H1 interface packet.
This also fixes the setting of bthci.sent, which is a gboolean that
should be TRUE for sent packets and FALSE for received packets, which
means it should *NOT* be set to P2P_DIR_SENT for sent packets and
P2P_DIR_RECV for received packets - P2P_DIR_SENT is 0, meaning it looks
like FALSE, not TRUE. and P2P_DIR_RECV is 1, meaning it looks like TRUE,
not FALSE. (In practice, this doesn't appear to matter, as the only
places that look at bthci.sent look it it *before* the packetlogger
dissector is called, but it's better to do it correctly, in case
anything else *does* end up looking at that field after the packetlogger
dissector is called.)
Use a dissector table instead of manually managing an array of dissector
handles with a hardcoded size. This also prevents a buffer over-read
from unexpected payload format values (either in a later version of
the protocol or just malformed data.)
Add value strings and units as appropriate from ETSI TS 103 221-2
V1.1.1. (The dissector still needs to be updated to V1.4.1)
Also change the XID field to a FT_GUID, as it is a version 4
UUID per RFC 4122.
IEEE 802.11 SSID fields are officially unspecified encoding but
probably UTF-8 (and likely ASCII, with which UTF-8 is backwards
compatible), unless the Extended Capabilities bit indicating that
it's *definitely* UTF-8 is set.
Get the SSID bytes as a raw byte string without any encoding
validation for sending to Dot11Decrypt, and add it to the tree
as a FT_BYTES with BASE_SHOW_UTF_8_PRINTABLE, which does the
right thing most of the time, and more often than now. In practice
this does most of #16208.
To really finish the job, the Extended Capabilities bit needs to
be checked, but not only does that bit come in a later tagged element
than the SSID, it's not necessarily sent, and for Responses we'd have
to track if the bit was set in a corresponding Request in the same
conversation. However, it's not clear that any drivers actually do
set the bit. (In all the captures I've seen with UTF-8 or even non
ASCII/non UTF-8 SSIDs, the bit was unset.)
Allow export PDU taps to be registered with a wiretap encapsulation
instead of always using WTAP_ENCAP_WIRESHARK_UPPER_PDU. This allows
creating normal capture files that aren't tied to wireshark without
having to do a "editcap -C -L -T", as well as creating files in
formats other than pcapng and pcap with tshark.
Provide a couple sample implementations in Ethernet (WTAP_ENCAP_ETHERNET)
and IP (v4 and v6, WTAP_ENCAP_RAW_IP) that are the most common use cases.
(I can imagine a few others; WTAP_ENCAP_MPEG_2_TS could probably be
useful, for example.) Fixes#15141
Correct spelling of from Queueing to Queueing.
This fixes issue #17943.
Note that other instances of "Queueing" are
kept because it's technically a correct spelling,
but here it's the name of the protocol.
Let's do what's done for u8, which looks far more sane.
Fixes following gcc 11.2.0 warning:
"""
epan/dissectors/packet-csn1.c:913:17: warning: ‘ui16’ may be used uninitialized in this function [-Wmaybe-uninitialized]
913 | memcpy(pui16, &ui16, 2);
| ^~~~~~~~~~~~~~~~~~~~~~~
"""
1. The fixed size of a Couchbase header is 24 bytes (not 12)
2. The "overflow detection" won't work as the test would wrap.
In addition to that the (current) version of the server will
drop a connection if it encounters a frame bigger than 30MB
and the biggest "legal" packets are currently less than 21MB.
Return NULL when an item with length zero or lower -1 is added to
the tree.
With this the calling dissector doesn't have to check the length and
there is no Dissector bug reported.
Related to #17890
A packet in the Couchbase protocol looks like:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| HEADER |
| |
| |
| |
+---------------+---------------+---------------+---------------+
24| Frame specific extras (only set if magic and length in the |
| header say so) |
+---------------+---------------+---------------+---------------+
x| Ccommand specific extras |
| (note length in the extras length header field) |
+---------------+---------------+---------------+---------------+
y| Key (as needed) |
| (note length in key length header field) |
+---------------+---------------+---------------+---------------+
z| Value (as needed) |
| (note length is total body length header field, minus |
| sum of the other sections above) |
+---------------+---------------+---------------+---------------+
This patch change the dissector to call a separate function to
print each section (instead of a single function).
The motivation for the patch is to make the code more readable
as each of these fields may have multiple formats (depending on
the value in the magic field). Currently only the client initiated
packets are implemented in the dissector, but in certain cases
the server may push messages to the client with a different magic
which use another namespace for the opcodes and would be a lot
easier to implement with this refactor)
In addition the hf_hello_features should be registered as
FT_NONE and not FT_STRING as it isn't a string (and would
cause the "expert info" to print a warning with "trailing
stray characters")
Added in d4499eb9 Changed to "1" in 507d07eda
Setting to "Ok" in UAT expert_severity (Edit->Preferences->Expert)
causes the associated protocol level to not be displayed in the
Packet Details protocol tree.
Example: ip.ttl.too_small set to "Ok" drops "ip" from the tree
It creates bluetooth_data_t what is The Center of the Bluetooth World in Wireshark,
most important is that bluetooth_data_t must provide shared trees (resources) to enable
dissection for non trivial relations in Bluetooth, for example mapping BDADDR to name.
Issue: 17570
Change-Id: Ice17b804ab6d4dcf0f77f1b2356a6712ce7e64b1
dissect_ntlmssp() is also called from dissect_spnego_T_mechListMIC(),
we should detect a 16 byte structure starting with 0x01
and use dissect_ntlmssp_verf().
All other messages in dissect_ntlmssp() start with the
magic string "NTLMSSP", so they never match the 0x01.
It fixes another problem seen in the example captures
of https://gitlab.com/wireshark/wireshark/-/issues/17958
Signed-off-by: Stefan Metzmacher <metze@samba.org>
If we have data remaining before the start of the variable data,
we should assume the space for the version field even without
the NTLMSSP_NEGOTIATE_VERSION flag. In that case we should
mark the 8 bytes as zero bytes.
This fixes https://gitlab.com/wireshark/wireshark/-/issues/17958
Signed-off-by: Stefan Metzmacher <metze@samba.org>
The L.4 adaptation header does not include a sync byte. Use the
current offset to get the ACM byte instead of hardcoding in the
value that is correct for L.2 and L.3.
There are four supported types of DVB Base Band Frame Adaptation Layer
headers, and they all can have false positives. Add a preference that
so that a user can either look for all four possible types, or can
only look for a packets that match the preferred type.
Fix#17950.
Replace the log PROTOCOL_BINARY_RESPONSE_ prefix to STATUS_ and
PROTOCOL_BINARY_CMD_ prefix to CLIENT_OPCODE_.
Couchbase do not support the memcached textual protocol so we'll
_always_ be using the binary protocol framing. In the couchbase
source code all of the PROTOCOL_BINARY_* constants was refactored
to enum classes and these two are called Status and ClientOpcode.
"Unfortuantely" this file is still in C so we can't reuse the
C++ enum classes directly so we'll need a prefix.
Huang Qiangxiong
Pau Espin