Alex Kirk wrote:
Quoting Guy Harris <gharris@xxxxxxxxx>:
A "packet" is a straight TCP packet; a "record" is a chunk of data within that
packet. Since I appear to have been confusing in my explanation, I'm attaching a
sample PCAP: packet #5 is the start of the PDU, and packet #6 is a continuation
(as well as the end of the PDU). The 4-byte length field, at the start of packet
#5 in this case is 2420; as you'll be able to see, there are exactly that many
bytes of data following in the PDU (i.e. in the remainder of packet #5's payload
and in the payload of packet #6, just for clarity's sake). After some header
data, the first "record" starts at offset 0x5A and goes through offset 0x89
(0xFFFFFFFF is the terminator; my search routine actually scans for 0xFF, and
then checks the next three bytes one at a time to see if we've got the
terminator). All of the remaining records are identical.
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.
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?
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.
