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 <g...@alum.mit.edu> wrote: > > On Sep 2, 2015, at 10:33 AM, Robert Cragie <robert.cra...@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-requ...@wireshark.org?subject=unsubscribe
