> On Jul 5, 2020, at 9:09 AM, Martin Mathieson via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> 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.
