ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Question on reported length

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Mon, 30 Jun 2008 18:14:03 -0400


Richard Achmatowicz wrote:
So:
1. When do I know to use tvb_length() versus tvb_reported_length() in general? Who sets the reported length? Is there a simple example of when the two lengths will need to be different? If the calling dissector's payload may also include padding why wouldn't it create a new tvb
which does not include the padding to pass to the called dissector?

The reported length is the length the packet was (or should have been) on the wire. The (regular) length is the length when it was captured. Think: using tcpdump with a "snapshot" length less than the MTU. "tcpdump -s 100" causes tcpdump to capture only the first 100 bytes of the packets (but it reports the length that was actually on the wire, too).

Wireshark keeps track of the 2 so we know what to tell the user if a dissector tries to read past the end of the tvb:

- if it's past the length but less than the reported length then the user will see "packet size limited during capture"
- if it's past the reported length then the user will see "Malformed packet"

2. Is there an explanation for why it is used in the context of this simple example? (does the fact that TCP calls the dissector in the example
have anything to do with the fact that tvb_get_reported_length() is used?)

It appears that it is doing that so if a snapshot length was used it will continue to try to read past the end of the tvb which will cause a "reported length violation" exception to be raised. (The alternative, to read only until the end of the tvb, would make it appear that the C string was full dissected whereas it was not.)