On Thu, Mar 26, 2020 at 7:44 PM Guy Harris <ghar...@sonic.net> wrote: > > Here's the proposal for "custom" link-layer types I threatened^Wpromised in > my earlier email. > > A link-layer type value of 0xFFFF will be reserved as LINKTYPE_CUSTOM, with > libpcap offering a DLT_CUSTOM. > > A custom link-layer type has a 32-bit IANA-registered Private Enterprise > Number (PEN): > > https://en.wikipedia.org/wiki/Private_Enterprise_Number > > https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers > > as is used for custom pcapng blocks and options. > > We could either 1) also say it should have a 32-bit per-vendor link-layer > type number or 2) say that if the vendor plans to use it for more than one > type of link-layer header, they have to arrange that the link-layer header > should begin with information necessary to determine what the *rest* of the > link-layer header is. > > 2) is more along the lines of the way custom block and options work. However: > > every non-custom block includes a block type, and every non-custom > option has an option type, but not every *block* in a capture file has a > link-layer header type - a pcap header has a link-layer type that applies to > all packets in the file and a pcapng IDB has a link-layer type that applies > to all packets on that interface; > > knowing the link-layer type up front makes it easier to generate BPF > filter code for an interface, if we support these types for live capture (or > if the vendor's private capture mechanism supports it); > > so I'm inclined to go with 1). > > In that model: > > in pcap files, if the lower 16 bits of the 32-bit link-layer type > value is 0xFFFF, the two "Reserved" fields (which were formerly a > rarely-if-ever-used and not-supported-by-libpcap-or-Wireshark time zone > offset and time stamp resolution) MUST contain the PEN and vendor-specific > link-layer type; > > in pcapng file, if the link-layer type in an IDB is 0xFFFF, the IDB > *MUST* contain a new option, containing the PEN and vendor-specific > link-layer type. > > Given that it's for *two* capture file formats, these lists are probably > better places for discussion than having two pull requests and discussing > them in comments there.
Sounds good to me. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___________________________________________________________________________ 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
