[pcap-ng-format] "Custom" link-layer types for pcap and pcapng
mcr at sandelman.ca
Fri Mar 27 14:59:57 EDT 2020
Guy Harris <gharris at sonic.net> wrote:
> 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):
That works, since many already have PENs, and for middle sized and small
entities, they will know what it is, and who controls it. For larger
entities, this will sadly be meaningless.
I think that this is a really good internal-only format.
> 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.
At first blush, I prefer to let the vendor figure it out...
> 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).
okay, so how would we be able to generate code for an encapsulation that we
don't know about?
> 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;
not a big fan of this, but okay.
> 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.
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
More information about the tcpdump-workers