[Rick Bywater <rbywater@xxxxxxxxxxxxx>]

Title: RE: [Ethereal-dev] RE: New version of the bssgp dissector "Patch"

Anders, thanks.  It looks like your fix worked on the UL problem.  Now, however, I seem to be running into a similar problem with certain DL Unitdata messages.  Attached is a capture which does not seem to get through the MS Radio Access Capability to the DRX parameter IE which follows. 

FYI, I found other DL Unitdata messages which did correctly decode.  If needed, I can get a capture file with both successfully and un-successfully decoded messages.  I will try to debug this over the weekend, but if you find a problem, I would appreciate you letting me know.

Thanks
Rick <<dl.pcap>>

-----Original Message-----
From:   Anders Broman (AL/EAB) [SMTP:anders.broman@xxxxxxxxxxxx]
Sent:   Friday, December 10, 2004 7:46 AM
To:     'Ethereal development'
Subject:        RE: [Ethereal-dev] RE: New version of the bssgp dissector "Patch"

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
 << File: bssgp.diff >>  << File: ATT10917.txt >>

THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED,  OR OTHER 
LEGALLY PROTECTED INFORMATION.  IF YOU ARE NOT THE INTENDED RECIPIENT
(EVEN IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY
OR RETRANSMIT IT.  IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE
REMOVED FROM A MAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT
 POSTMASTER@xxxxxxxxxxxxx, THEN DELETE.  THANK YOU.

Attachment: dl.pcap
Description: Binary data