On Jul 19, 2019, at 5:52 AM, Holger Pfrommer <HPfrommer@xxxxxxxxxxxx> wrote:
> Now my question: I would be very useful to use pcap’s caplen and len values to report original packet length while a capture device adds additional data to a frame, for example a header containing some more details about the frame itself.
It might be very useful to, in some fashion, indicate that additional information has been added by a capture device.
It would be *incorrect* to use the capture length in a record (pcap, pcapng, or other file type) to indicate the length of on-the-wire data plus additional data, because the capture length is intended to indicate the length after "slicing".
If an additional header is added, that should be indicated by using a different link-layer header type; see, for example:
LINKTYPE_IEEE802_11, in which the packet data begins with an IEEE 802.11 header, vs. LINKTYPE_IEEE802_11_RADIOTAP, in which the packet data begins with a radiotap header giving radio information, followed by an 802.11 header;
LINKTYPE_DOCSIS, in which the packet data begins with a DOCSIS MAC frame header, vs. LINKTYPE_DOCSIS31_XRA31, in which the packet data begins with a metadata header giving additional frame information, followed by a DOCSIS MAC frame or other DOCSIS packet header;
LINKTYPE_ETHERNET, in which case the packet data begins with an Ethernet header, vs. LINKTYPE_NETANALYZER, in which case the packet data begins with a metadata header giving additional information about the packet, followed by an Ethernet header.
Note also that a capture device could both add a metadata header *AND* slice the frame; it's not as if adding a header at the beginning and slicing data off at the end are mutually exclusive.
