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.
The Aeron specification says nothing about it being null-terminated, and
in at least some captures, it's not null terminated.
Make it an FT_STRING, rather than an FT_STRINGZ.
Clean up a comment so that more of the URL is visible in a narrower
window.
MariaDB and MySQL are not longer drop-in compatible, they differ in very
different directions
for protocol and api. This patch contains support for MariaDB specific
commands and extensions:
- MariaDB specific character sets and collations (also updated MySQL
collations)
- MariaDB extended capabilities in greeting and login packets
- Support for MARIADB_STMT_BULK_EXECUTE command
- Removal of "5.5.5-" prefix in the version string.
These parameters are used by latest GQUIC versions.
Pcap examples are available in #16825
I noticed that gquic::dissect_gquic_tag() and gquic::dissect_gquic_tags()
don't really need the gquic_info parameter: remove it
The Windows runners are constrained by the following:
* We require quite a bit of software not present in the stanadard
runner[1] which takes a long time to install, including Python, Perl,
and Qt.
* You can't specify an arbitrary Docker image like you can with Linux
runners.
As a result we have a project-specific runner for wireshark/wireshark
that runs a custom Windows Docker image. Update the CI rules so that
merge-request:windows only runs for gitlab.com/wireshark/wireshark. The
GitLab documentation recommends rules over only/except, so switch to
them.
Fixup .editorconfig while we're here.
[1]https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md
Both osmocom and TTCN3 Titan are parsing Handover Request with an IPv6
Transport layer Address just fine, but wireshark was showing it as
malformed. Parsing the address similar to what is done in IPv4 fixes the
issue.
check_spelling.py scans Wireshark source or documentation files,
using the general dictionary from pyspellcheck, augmented by the contents
of wireshark_words.txt.
Can scan:
- entire folders (recursively)
- individual files
- open files
- files affected by recent git changes