Guy,
Thanks for the explanation.
As I understand it should be no problem to activate the (partial) second
part of the CLNP decoding. I hope to see it implemented in one of the future
releases of ethereal.
Sorry, I messed up on the file. I've included a new one below in case you
need it for testing.
<<temp.enc>>
With kind regards,
Rob Zuidweg
Lucent Technologies O
Customer Technical Support -SDH
* +31 35 687 5328
* +31 35 687 5971 FAX
* +31 35 687 1555 Help Desk
*mailto:zuidweg@xxxxxxxxxx
* P.O. Box 18
Botterstraat 45
1270 AA Huizen
The Netherlands
----------
From: Guy Harris [SMTP:gharris@xxxxxxxxxxxx]
Sent: dinsdag 19 december 2000 18:52
To: Zuidweg, R (Rob)
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] IS-IS CLNP decoding of ethereal vs
sniffer
On Tue, Dec 19, 2000 at 01:23:02PM +0100, Zuidweg, R (Rob) wrote:
> A question regarding CLNP packet decoding.
> I'm using ethereal to troubleshoot IS-IS networks and found that
CLNP error
> reports are decoded differently between ethereal and NAI's
sniffer.
>
> In case of a destination unknown package, the sniffer decodes the
CLNP
> error-report PDU as well as the CLNP data PDU. Ethereal only
decodes the
> error report PDU.
> In order to find out the original SA and DA decoding of the data
PDU is also
> required.
>
> Is it a bug that after the first cnlp packet in a frame other cnlp
packets
> are no longer decoded, or is this a design choice?
To quote a comment in the CLNP dissector:
case ER_NPDU:
/* The payload is the header and "none, some, or all of the
data
part of the discarded PDU", i.e. it's like an ICMP error;
just as we don't yet trust ourselves to be able to dissect
the payload of an ICMP error packet, we don't yet trust
ourselves to dissect the payload of a CLNP ER packet. */
and to quote a comment in the ICMP dissector:
/* Decode the IP header and first 64 bits of data from the
original datagram.
XXX - for now, just display it as data; not all
dissection
routines can handle a short packet without exploding. */
Now, given that I think all sub-dissectors of the CLNP dissector
have
been tvbuffified - and given that we're likely to tvbuffify any
future
contributed non-tvbuffified dissectors - it may be safe to dissect
the
partial discarded PDU, as any tvbuffified dissector will get an
exception if it goes past the end of the packet so that an attempt
on
its part to do so will be handled cleanly.
> One other unrelated question is: what is the function of the
plugins? Is
> there any documentation on either plugin types or formats to
create your
> own?
Plugins are written almost exactly like compiled-in dissectors, with
some exceptions; see the "doc/README.*" files in the Ethereal source
tree. They are built as dynamically-loadable modules for whatever
OS
you're using; see the "plugins/gryphon" and "plugins/mgcp"
directories
for examples (you also have to update "plugins/Makefile.in" and
"plugins/Makefile.nmake" to include the directory in which your
plugin
resides).
> I'll include the following files to show the difference in
decoding for
> ethereal and sniffer
>
>
> erpdu.etr CLNP error report in libpcap format
It's actually an empty capture (just 24 bytes of file header, and no
packets).
Attachment:
temp.enc
Description: Binary data