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

Ethereal-dev: [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, 3 Feb 2005 10:03:07 -0500
Hello All,

I'm making my first attempt at reassembling PDUs that span multiple TCP packets,
and I've run into an odd result that is either due to my misunderstanding the
reassembly paradigm (likely) or some sort of issue with tvb_find_guint8()
(probably not, unless it's that I don't properly understand it).

The situation is this: my PDU begins with a 4-byte field that gives me its
length. Following the instructions in README.developer, I've been able to get a
tvb whose size, as shown by tvb_reported_length_remaining(), is correct. During
dissection, I have a function that searches for a record terminator with
tvb_get_guint8() (since these long packets should only ever be a series of
records with a specific terminator). Using either -1 or the remaining length of
the packet (given by, again, tvb_reported_length_remaining(tvb,
current_offset)), however, tvb_get_guint8() always fails to find record
terminators that are beyond the current packet's boundary in the tvb. For
example, if the packet ends at 1440 bytes, but tvb has a reported length of 2880
with a terminator at 1450, tvb_get_guint8() never finds that terminator.

Is this behavior to be expected? If so, then obviuosly my approach of treating
the PDU like one big packet and continuing to add branches to the dissection
tree irrespective of packet boundaries is incorrect, and I need some guidance as
to how to dissect data that comes in the 2nd -> Nth packets of a PDU (assuming
that I even *can* do this; if not, I need to figure out how to at least turn off
dissection in these packets, so that they're not incorrectly dissected). If not,
then hopefully I can provide enough detail that the problem can be solved.

Thank You,
Alex Kirk