Jonty Ray wrote:
< I Can
successfully see it in Ethereal version 0.9.7, which I have been using till
now.
I think that I found something
interesting.
The "fastStart item length" is 36 for Item 0, but
it seems that the h225 dissector is not using that information, so it
continues
to dissect the next fastStart item without
skipping any padding bytes (at least it seems that there is some kind of
padding in your
capture that I haven't seen in other
captures).
I tried to do some small modifications i
dissect_h225_fastStart_item so that the new offset is calculated from item
length
and that seems to solve the problem. Howver I
have just tested with one capture yet.
The solution below is just the preliminar I used.
I need to check more details regarding this and there is currently a
warning
due to unsigned/signed mismatch.
Maybe there is a few other places in the
code where you need to do similar things.
static
int
dissect_h225_fastStart_item(tvbuff_t *tvb, int offset, packet_info
*pinfo, proto_tree *tree)
{
guint32 length;
guint32
newoffset;
offset=dissect_per_length_determinant(tvb,
offset, pinfo, tree, hf_h225_fastStart_item_length,
&length);
newoffset = offset + (length<<3); /* please
note that offset is in bits in PER dissectors, but the item length is in
octets */
offset=dissect_h245_OpenLogicalChannel(tvb, offset,
pinfo, tree);
contains_faststart = TRUE;
return
newoffset;
}