|
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;
}
| 
