Re: Why is conflict check on the buildbot green?

[Guy Harris <gharris () sonic net>]

> 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-request () wireshark org?subject=unsubscribe