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: "Zuidweg, R (Rob)" <zuidweg@xxxxxxxxxx>
Date: Wed, 20 Dec 2000 16:35:07 +0100
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