| Bug ID |
12526
|
| Summary |
Wireshark doesn't separate pseudoheader lengths from packet wire lengths
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Capture file support (libwiretap)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
RFC following on from a group discussion at Sharkfest 2016:
Wireshark maintains in struct wtap_pkthdr for each 'packet' a 'len' which is
the number of bytes of the packet on the wire plus any capture system related
pseudoheaders, and the 'caplen' which is the number of available bytes of
packet from the wire plus such capture pseudoheaders.
This means that Wireshark displays wtap_pkthdr.len as "X bytes on the wire (8*X
bits)" and "Frame Length: X" even though this value includes any capture system
pseudoheaders which were NOT present on the wire.
For example in usb_u3v_sample.pcapng Frame 2 the Frame Length (frame.len) is
66, even though the USBPcap pseudoheader length (usb.usbpcap_header_len) is 28
and the Packet Data Length (usb.data_len) is 38. The same occurs for Capture
Length.
The same effect would occur for ERF pseudoheaders except that we strip them off
in the wtap layer, hence preserving the len and caplen interpretations. This
means we cannot dissect the ERF pseudoheaders with tvb accessors, nor display
their offsets in the hex view, nor encapsulate them in other protocols (in
which case they would actually be on the wire).
I think that including capture pesudoheader lengths in the reported 'Frame
Length' is misleading for users, and could lead to incorrect bandwidth
calculation if not corrected.
If we encourage the dissection of capture pseudoheaders with epan as 'frame
bytes' instead of stripping them in wtap, then we should track the number of
bytes of pseudoheaders in wtap_pkthdr as a separate variable (pheader_len, or
nonwire_len?). Display of 'packet wire length' and calculations of bandwidth
should be updated to subtract this non-wire length.
The alternative is that every dissector for a capture pseudoheader has to
implement an ad-hoc 'real wire length' attribute such as usb.data_len, which
may not be used instead of frame.len when appropriate.
Another alternative might be to add a new "wire_length" variable to the struct
wtap_pkthdr to track the wire-only length explicitly, but this would mean wider
changes in both wtap and UI code.
Comments?
You are receiving this mail because:
- You are watching all bug changes.
