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.
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.