Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 7564] A packet is recognized as 8 bytes long while it is a

Date: Fri, 3 Aug 2012 16:41:54 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7564

--- Comment #4 from Guy Harris <guy@xxxxxxxxxxxx> 2012-08-03 16:41:53 PDT ---
(In reply to comment #3)
> First byte is libpcap_ppp_phdr direction, and the problem is that libwiretap
> don't treat pseudo headers as packet data.

...for this particular link-layer header type.  For some other link-layer
header types, e.g. Linux USB and various pcap/pcap-ng 802.11 radio headers, it
*does* treat them as packet data.

The advantages of not treating them as packet data are that:

    multiple flavors of capture-file metadata for the same underlying physical
link layer could be mapped to a "common" form of metadata, so we only need one
dissector for the metadata and could read a file with one flavor of metadata
and write it out with a different flavor of metadata as long as the underlying
physical layer is the same;

    they don't get counted as over-the-wire data by software that treats all
"packet data" as supplied by libwiretap as over-the-wire data.

The main *dis*advantage of not treating them as packet data is that:

    the "common" form of metadata is a bit of a Procrustean bed, and if some
particular bit of metadata can't be represented in the common form, the common
form needs to be changed to support it, and if the metadata is as extensible
as, say, radiotap data, we *can't even know* all the forms of metadata present,
so it's an endless race to keep up - and that would mean that we might discard
metadata if we're reading a radiotap file and writing the packets out to a
radiotap file.

As per the second of the advantages listed above, there are arguments that can
be made in favor of the notion that the packet really *is* 8 bytes long - that
direction byte didn't go over the wire, it was added by whatever code wrote out
the byte to the file.  Even in the cases where we treat packet metadata
supplied as part of the packet data in a capture, we should probably report the
packet length as *NOT* including the metadata, regardless of what the pcap API
puts into the "len" or "caplen" field of the "struct pcap_pkthdr" when you read
the packet.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.