Ethereal-dev: Re: [Ethereal-dev] IS-IS CLNP decoding of ethereal vs sniffer

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

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Tue, 19 Dec 2000 09:52:02 -0800
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).