Updated https://code.wireshark.org/review/#/c/37711/ which is now merged, and also created https://code.wireshark.org/review/#/c/37733/ (where more extension/next headers are filled in from IANA registry).
On Sun, Jul 5, 2020 at 9:28 PM Guy Harris <ghar...@sonic.net> wrote: > > > > On Jul 5, 2020, at 9:09 AM, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > > > > I added https://code.wireshark.org/review/#/c/37711/ for the DVB-S2-BB > one. It is a range_string, where arguably a value_string would be clearer, > but the linked-to documentation is currently unavailable. > > If you're referring to the document whose URL is listed in the initial > comment in packet-dvb-s2-bb.c, it is available on the Wayback Machine: > > > https://web.archive.org/web/20170226064346/http://satlabs.org/pdf/sl_561_Mode_Adaptation_Input_and_Output_Interfaces_for_DVB-S2_Equipment_v1.3.pdf > > Unfortunately, it doesn't document that field, however. > > The header being parsed is a Generic Stream Encapsulation header, as > described in ETSI TS 102 606-1: > > > https://www.etsi.org/deliver/etsi_ts/102600_102699/10260601/01.02.01_60/ts_10260601v010201p.pdf > > That specification says, in section 4.1.2 "Network Protocol > Identification": > > The GSE Header includes a 2 byte Protocol Type/Extension field > that indicates the type of protocol carried by the PDU. The Protocol Type > field is given in the GSE Header for each complete PDU or the first > fragment of an encapsulated PDU and uses the method defined in the > Unidirectional Lightweight Encapsulation (ULE) protocol [5]. Extension > headers may therefore be defined as in ULE. This approach allows efficient > support for a number of PDU formats, including IPv4, IPv6, Ethernet, MPLS, > arp, 802.1pQ, etc. and permits inclusion of new protocol types. Moreover, > it provides a format for Layer 2 security mechanisms, providing functions > such as encryption, identity hiding, and authentication methods, without > modification of the GSE Header structure. > > and, in section 4.2 "GSE Packet Format", subsection 4.2.1 "Specification": > > Protocol_Type: This 16-bit field indicates the type of payload > carried in the PDU, or the presence of a Next-Header. The set of values > that may be assigned to this field is divided into two ranges, similar to > the allocation of Ethernet and shall follow the rules described in [5]. The > two ranges are: > > Type 1: Next-Header Type field > > The first range of the Type space corresponds to the range of > values 0 to 1535 decimal. These values may be used to identify > link-specific protocols and/or to indicate the presence of Extension > Headers that carry additional optional protocol fields (e.g. a bridging > encapsulation). The range is sub-divided into values less than 256 and > greater than 256, depending on the type of extension. The use of these > values is co-ordinated by an IANA registry [5]. > > Type 2: EtherType compatible Type Fields > > The second range of the Type space corresponds to the values > between 0x600 (1536 decimal) and 0xFFFF. This set of type assignments > follow DIX/IEEE assignments (but exclude use of this field as a frame > length indicator). All assignments in this space shall use the values > defined for EtherType, the following two Type values are used as examples > (taken from the IEEE EtherTypes registry): > > EXAMPLE: 0x0800: IPv4 payload > 0x86DD: IPv6 payload > > So the answer to the question "should this be a range_string or a > value_string" appears to be... > > ..."no". > > Instead, there should be *two* fields used. > > If the value is < 1536, it's a next-header type; the reference for that > is, to quote the ETSI spec: > > IETF RFC 4326: "Unidirectional Lightweight Encapsulation (ULE) for > Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)". > > That says, again, that values >= 1536 are Ethertypes, and lists 3 values > for the Next Header range: > > 0x0000: Test SNDU (see section 5.1) > 0x0001: Bridged Frame (see section 5.2) > 0x0100: Extension-Padding (see section 5.3) > > to quote the RFC. RFC 4326 speaks of two ranges, 0-255 and 256-511, for > those values, and the two registries appear to be "Mandatory Extension > Headers (or link-dependent type fields) for ULE (Range 0-255 decimal)": > > > https://www.iana.org/assignments/ule-next-headers/ule-next-headers.xhtml#ule-next-headers-1 > > and "Optional Extension Headers for ULE (Range 256-511 decimal)": > > > https://www.iana.org/assignments/ule-next-headers/ule-next-headers.xhtml#ule-next-headers-2 > > If, however, the value is >= 1536, it should be treated as an Ethertype.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
