Alex Kirk wrote:
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.
OK, so what's a "packet" and what's a "record" here? Is a PDU a
"packet" or a "record", or none of the above, e.g. with a "packet" and a
"record" being the same thing, with multiple "packets"/"records" in a PDU?
It sounds from "since these long packets should only ever be a series of
records with a specific terminator" as if a PDU is a "packet", where the
packet boundaries are determined by the 4-byte length field, and the
"records" are delimited by terminator bytes.
If so, then, if "the packet ends at 1440 bytes", but "tvb has a reported
length of 2880", does that mean that the 4-byte length field had a value
of 1440 or 2880?
If it's 1440, then the PDU/packet is 1440 bytes long, so it shouldn't be
surprising that "tvb_get_guint8()" doesn't find a terminator at 1450.
It is, however, surprising that the tvb has a reported length of 2880,
as the tvbuff should have the PDU/packet length as the reported length.
If it's 2880, then if "the packet ends at 1440 bytes", does that mean
that the "packet" is a record with a 2880-byte PDU, rather than being
the PDU?
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
OK, so *that* sounds as if a "packet" is a "record", rather than a PDU.
If you have a 2880-byte PDU with the first 1440 bytes being the first
packet, and a terminator at an offset of 1450, I presume the extra 10
bytes are some sort of trailer not considered part of the packet.
If there is a terminator byte with a particular value at an offset of
1450 from the beginning of the tvbuff, then a call
terminator_offset = tvb_find_guint8(tvb, 0, {value});
should find that terminator byte, as should any other call with the
offset argument being <= 1450. (Obviously, a call with an offset > 1450
won't find it.) Is that not happening?
