Re: tvb_captured_length or tvb_reported_length?

[Robert Cragie <robert.cragie () gridmerge com>]

Thanks for all your responses - much clearer now. I have used what I think
is right for what I am doing and all seems OK. On a quick review of all the
code, all I would say is that some of the uses are probably inconsistent
with what has been said.

Robert

On 2 September 2015 at 19:05, Guy Harris <guy () alum mit edu> wrote:

> On Sep 2, 2015, at 10:33 AM, Robert Cragie <robert.cragie () gridmerge com>
> wrote:
>
> > I am trying to understand the changes to the previous use of
> tvb_length(). There are now two functions
>
> There have *always* been two functions; that was not changed.  They were
> originally:
>
>         tvb_length()
>         tvb_reported_length()
>
> and the change was that we renamed the first of those to
> tvb_captured_length(), to make it clearer that it isn't *THE* length of the
> tvbuff and shouldn't be used by default.
>
> > (and their associates):
> >
> > * tvb_captured_length()
> > * tvb_reported_length()
> >
> > As far as I can tell, tvb_captured_length() is the direct replacement
> for tvb_length()
>
> It's a new *name* for tvb_length().
>
> > but tvbuff.h says "You probably want tvb_reported_length instead.".
>
> Which was true before the rename and is still true after the rename().
>
> > The use of both seems to be mixed throughout the files and it's
> difficult to follow the relationship between the two. So any guidance on
> this would be appreciated.
>
> libpcap/WinPcap supports something that could be called "packet slicing".
> They allow a "snapshot length" to be specified when capturing, and, if a
> packet is longer than the "snapshot length", only the first "snapshot
> length" bytes of the packet are provided to the application capturing
> packets.  They provide both the original length of the packet, before
> slicing is done, and the length to which it was sliced.  If the snapshot
> length is sufficiently large, no slicing is done, and the two lengths are
> the same.
>
> The pcap and pcapng file formats record both lengths, as, if slicing was
> done, not all of the packet's data is necessarily present in the file.
> tcpdump and Wireshark/TShark/dumpcap support setting the "snapshot length".
>
> This is not unique to libpcap/WinPcap; some packet sniffers that don't use
> libpcap/WinPcap also support slicing, and save both the original length and
> the length after slicing in the file.
>
> tvb_reported_length() gives the length of the protocol data based on the
> original length.  tvb_captured_length() gives the amount of that protocol
> data that is available after slicing was done.
>
> Telling the user that some field is N bytes long when it was, in fact, M
> bytes long, but sliced to N bytes in the capture process, is an error, so,
> when reporting the number of bytes in a field or in a protocol's payload,
> tab_reported_length() should always be used -
> tvb_length()/tvb_captured_length() shouldn't have been used and shouldn't
> be used.
>
> When processing data to the end of the payload, the "to the end of the
> payload" loop should use tvb_reported_length(), so that if the dissection
> stops because you run out of *unsliced* data, and there would have been
> more data to dissect had slicing not been done, the dissection is stopped
> by an exception being thrown, and the packet is marked as having been cut
> short by the capture process, so the user knows that the packet actually
> contained more data than shows up in the dissection.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe