Hi,
It looks like it could be fixed calculating the lengt correctly.
Best rgards
Anders
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Guy Harris
Sent: den 10 december 2004 11:40
To: Ethereal development
Cc: 'a.broman@xxxxxxxxx'
Subject: Re: [Ethereal-dev] RE: New version of the bssgp dissector
Rick Bywater wrote:
> I tested this new dissector and it seems to have a handoff issue to llc. I
> am attaching a capture file which illustrates the problem if you have a
> chance to investigate.
The older dissector appears to have the same problem, if you mean that
the second IE after the "Cell Identifier" IE isn't dissected as the
contents of an LLC PDU.
The dissector appears to assume that a packet of a given type always has
IEs of particular types in a particular order. That might be what the
spec requires, but a dissector should, if possible, handle packets that
*don't* match what the spec requires as best as possible, given that one
purpose of a dissector is to debug network problems caused by packets
that don't match what the spec requires - and because that might make it
easier to diagnose *dissector* problems where they don't match the spec.
Unfortunately, it appears that the TLLI IE comes in two flavors - one
that's a TLV, and one that's just a V - so it might take a bit more work
to come up with a common dissector that handles all the IEs in a
particular packet type. I looked at that at one point - *IF* I remember
correctly, a given PDU starts with zero or more V IEs, the sequence of
which is specified by the PDU type, followed by zero or more TV or TLV
IEs, so the dissector for a particular IE could dissect the V IEs (which
presumably all have to be there, in the precise order specified by the
spec, otherwise the packet is unparseable - and there's no way to detect
that they're *not* all present in that order, as there are no tags), and
then call a common TV/TLV dissector that dissects the remaining IEs.
I'll have to dig up the stuff I did earlier (but didn't have time to
finish) to see if it could be used here. The code, and tables, might be
a fair bit simpler, and easier to check for correctness, if done in that
fashion.
The *particular* problem here might be that the offset is advanced by
too many bytes after dissecting a Cell Identifier IE, but that's just
based on a very quick look at TS 48.018 V6.6.0 and at the packet in
question.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
Attachment:
bssgp.diff
Description: Binary data