OK. I think i've got it.
There is an option "limit each packet to xxx bytes" in Caputure->Options which
allows capturing a prefix of a packet instead of the full packet length, and
these functions allow differentiating between why we may have
reached the end of the tvb buffer before all packet data was processed.
Thanks!
On Mon, Jun 30, 2008 at 6:14 PM, Jeff Morriss <
jeff.morriss.ws@
gmail.com> wrote:
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.)
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev