Re: Why is conflict check on the buildbot green?

[Martin Mathieson via Wireshark-dev <wireshark-dev () wireshark org>]

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