"Custom" link-layer types for pcap and pcapng

Guy Harris gharris at sonic.net
Thu Mar 26 22:43:11 EDT 2020

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):



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.

More information about the tcpdump-workers mailing list