On Wed, May 23, 2001 at 03:25:53PM +1000, Ronnie Sahlberg wrote:
> (if it has holes, there is no point in dissectong it)
Yes, there is.
There are a number of reasons why there might be "holes":
there might be "holes" due to a too-small snapshot length;
there might be "holes" due to missing frames (whether because
they weren't transmitted, or because they weren't captured).
If all the data the dissector would look at is present (e.g., because
the "holes" all correspond to unused fields in packets, unlikely though
that may be), the entire packet can be dissected, and if *not* all the
data the dissector would look at is present, the dissector will
eventually throw an exception - but it might not do so before doing some
useful dissection of what data *is* there.
This is really just a generalization of the current notion of packets
having a captured length shorter than the reported length.
> I dont know yet how this would affect the tvb_lengthXXX functions. What is
> the remaining length if there are holes? To the end of the last populated
> fragment?
The length would be from the starting offset (0 for "tvb_length()", the
offset argument for "tvb_length_remaining()") to the first piece of
missing data following it, whether it's missing because the frame
starting at that offset is "short" (captured length < reported length)
or because that frame or a subsequent frame is missing.
The *reported* length would be the length from a starting offset of 0 to
the end of the packet, to the extent that can be determined by the
reassembler.
