On Jul 19, 2019, at 5:52 AM, Holger Pfrommer <hpfrom...@hilscher.com> 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.
___________________________________________________________________________
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

Reply via email to