Ethereal-dev: Re: [Ethereal-dev] RE: New version of the bssgp dissector

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Fri, 10 Dec 2004 02:40:27 -0800
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.