Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Reassembly & tvb_find_guint8()

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Alex Kirk <alex@xxxxxxxxxxxx>
Date: Thu, 10 Feb 2005 09:54:18 -0500
> OK, so tcp_dissect_pdus() has presumably already done the reassembly, 
> and handed your dissector a 2424-byte tvbuff that starts with the data 
> at an offset of 0x42 from the beginning of packet #5 - i.e., the first 
> four bytes of the tvbuff are 00 00 09 74.
> 
> So the first record starts at an offset of 0x18 from the beginning of 
> that tvbuff, and goes through offset 0x47 of that tvbuff, with 0x47 
> having the last FF in the terminator.

Correct. Obviously having the PCAP was helpful. :-)

> > next_terminator = tvb_find_guint8(tvb, offset, -1, 255);
> > 
> > I had inserted a bunch of fprintf() calls in my function, to watch where
> > terminators were being found, the size of tvbuff, etc. The output should
> be
> > pretty self-explanatory:
> > 
> > ...
> > In find_record_terminator, size of tvb: 2424, tvb remaining, 1056, offset:
> 1368
> > Next terminator: 1412
> > Success: record ends at 1416
> > In find_record_terminator, size of tvb: 2424, tvb remaining, 1008, offset:
> 1416
> > Next terminator: -1
> 
> So those are offsets within the tvbuff, rather than offsets within 
> packet 5, right?

Again, correct. I set offset = 0 at the start of dissection and increment it
each time I parse a given field/set of fields. Offset 0 is the same as byte 0x42
in packet 5 (which starts our 0x00000974 length field).

> > Since I know that there's *at least* one more terminator byte in my tvbuff,
> that
> > shouldn't be happening. I suspect that the problem is because there are no
> more
> > terminators left in packet #5, which should end at offset 1448 of tvbuff.
> 
> That *shouldn't* be happening.  Could you send a copy of your WINS 
> dissector, so we can see whether there's a bug somewhere in the tvbuff 
> code?  I suppose it's possible that some remnant of the packet 
> boundaries are still around in the reassembled tvbuff, although I'm not 
> sure where that'd happen.
> 

I've attached it. Keep in mind that this is still not a finished product, and as
such is not yet intended for formal publication. Hopefully it's good enough to
at least let you determine whethere there is a bug in the tvbuff code. :-)

Alex Kirk

Attachment: packet-wins.c
Description: Binary data