Move the pre-commit and validate-commit checks to their own job. This
lets us quickly re-run validate-commit in case the submitter forgets to
check "Allow commits from members who can merge to the target branch"
Shorten the "merge-request" prefix to "merge-req" in order to make it
easier to distinguish between each job in the GitLab UI.
Remove the old posix_v1 code which no clients ever implemented and add
code to dissect current version of the POSIX extensions as implemented
by the Linux kernel client (cifs.ko).
Gap items have a null field_info pointer, so set "Unknown" as the
default representation string and fill it in after we've established
that field_info is valid. Closes#16851.
Pass the value of the NDS class definition type to process_multivalues()
as the vflags, rather than the NDS flags, as that's what the
MVTYPE_CLASS_NAMES case in process_multivalues() is expecting.
That way, the class definitions will be dissected correctly.
FT_NONE items all have the name "Text Item" which makes it look
poor in the packet diagram.
For these fields, switch to use ->representation insead of ->name
to make these fields look more meaningful.
SMB2 is a protocol that consists of two FT_NONE expansions,
one for the Header and a second for the actual Command.
This makes packet diagram show this much nicer.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
FieldInformationGraphicsItem's constructor allocates a FieldInformation
which is never freed.
Opening MTP3 statistics for any capture file causes memory leaks.
Indirect leak of 1120 byte(s) in 10 object(s) allocated from:
#0 0x55e32cf19a42 in operator new(unsigned long)
#1 0x7f4cca598661 in QObject::QObject(QObject*)
#2 0x55e32d5f397f in PacketDiagram::addDiagram(_proto_node*)
...
Indirect leak of 400 byte(s) in 10 object(s) allocated from:
#0 0x55e32cf19a42 in operator new(unsigned long) ...
#1 0x55e32d5fce04 in FieldInformationGraphicsItem::FieldInformationGraphicsItem(...)
#2 0x55e32d5f397f in PacketDiagram::addDiagram(_proto_node*)
...
Add a FieldInformationGraphicsItem destructor and delete FieldInformation there.
Even if Q046 is an old version, it is still used by the current QUICHE
implementation.
In this way, the latest Wireshark is able to dissect all GQUIC versions
supported by recent Chrome (Q043,46,50 and T050,51), i.e. all GQUIC versions
that you can find in live traffic right now.
Pcap examples are available in #15984 and in the attachment.
Some Q046 information are available in:
https://docs.google.com/document/d/1FcpCJGTDEMblAs-Bm5TYuqhHyUqeWpqrItw2vkMFsdY/edit#heading=h.32qkkficm7zaClose#15984
FT_STRINGZPAD is for null-*padded* strings, where the field is in an
area of specified length, and, if the string is shorter than that
length, all bytes past the end of the string are NULs.
FT_STRINGZTRUNC is for null-*truncated* strings, where the field is in
an area of specified length and, if the string is shorter than that
length, there's a null character (which might be more than one byte, for
UCS-2, UTF-16, or UTF-32), and anything after that is not guaranteed to
have any particular value.
Use IS_FT_STRING() in some places rather than enumerating all the string
types, so that those places get automatically changed if the set of
string types changes.
In process_multivalues(), we create a protocol item for the attribute
syntax, but we don't fetch its value, and don't pass it to
print_nds_values() as the syntax argument; instead, we pass a variable
that wee initialize to 0, but never set. (One of the disadvantages of
preemptively initializing local variables is that data flow analyzers in
compilers and static analyzers can't point out that you didn't set the
variables in question to *useful* values.)
This fixes the dissection of NDS Read replies.
This field is actually a bitmask of four bits. It's somewhat odd
to decode it using a value_string. In any case, the values were
plain wrong (shifted to the left by '1').
See Figure A.3 of ITU-T Q.933
A related pcap file can be found at
https://people.osmocom.org/laforge/pcap/gsmtap-fr-q933-pvc_status.pcap
The mask applied to the final octet of the PVC Status IE must be 0x0E,
not 0x0A. The current code masks out the active bit, printing a '.'
instead of it.
See Figure A.3 of ITU-T Q.933
A related pcap file can be found at
https://people.osmocom.org/laforge/pcap/gsmtap-fr-q933-pvc_status.pcapc
In File Search Continue requests, the path is a single byte giving the
string length, followed by that many bytes containing the string value.
However, in at least some File Search Continue requests, the string
length value is longer than the string, and there's a NUL, followed by
other non-zero cruft, in the string.
FCNO Improve field display
FOPA Improve field display
FCMI Support new structure
GMO Support version 4
LPOO Improve field display
ID Initial Data Improve field display
PMO Improve QName display in COL_INFO
CONN Improve field display
To quote the GenDC 1.1 specification, section 2.2.2 "GenDC Container
Header Description":
Unique signature identifying a GenDC Container: a FourCC code
encoded as 4 ASCII characters not null terminated ...
so it's FT_STRING, not FT_STRINGZ.
Give the URL for a page pointing to all GenICam standards, including the
GenDC standards, version 1.0 and 1.1.
According to the Novell IPX Router Specification, Chapter 4 "Service
Advertising Protocol (SAP)":
Server Name
This field contains the 48 byte character string name that is
assigned to a server. The Server Name, in combination with the
Service Type, uniquely identifies a server on an internetwork.
Although SAP response packets always include the full 48 bytes
for this field, typical server names are usually less than 48
characters long and are ASCII NULL terminated. The contents of
the unused bytes which follow the NULL terminator are undefined.
which seems to indicate that a full 48-byte name will not have a null
termintor. It also indicates that the field isn't null-padded, just
"null-terminated if it's not terminated by the end of the field's fixed
length"; perhaps we need to distinguish between the former and the
latter, although it's not clear what would be a good short name for the
latter.
In any case, it sounds as if it's not guaranteed to be null-terminated.
As per IEEE Std 802.1Q-2016, section 13.8 "MST Configuration Identifier
(MCID)",
The Configuration Name, a variable length text string encoded
within a fixed field of 32 octets, conforming to IETF RFC 2271's
definition of SnmpAdminString. If the Configuration Name is
less than 32 characters, the text string should be terminated by
the NUL character, with the remainder of the 32-octet field
filled with NUL characters. Otherwise, the text string is
encoded with no terminating NUL character.
so it's not FT_STRINGZ, it's FT_STRINGZPAD.
This applies to other configuration names as well.
Gerald Combs
Harald Welte