Ethereal-dev: [Ethereal-dev] Re: [Ethereal-users] ethereal to csv

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Mon, 1 Jul 2002 14:34:45 -0700
On Mon, Jul 01, 2002 at 04:24:52PM +0200, Roger Kalden (EED) wrote:
> My question is now what is needed to implement this.  Is it possible
> to do this in a generic way,

Yes.

> or is it needed to adapt all protocol dissectors?

No.

> I went
> through the source code, but I am not so sure how generic the output is
> handled.  I believe each dissector handles the output on its own, right?

No.

What each dissector does, if a "protocol tree" for the packet is being
constructed, is add to that protocol tree.

A protocol tree contains items for named fields that a dissector has
registered and/or text-only entries for unnamed fields.

The printed and displayed output is constructed from the protocol tree;
each node in the protocol tree contains a text representation of the
field.

For text-only items, the text representation is constructed by
individual dissectors.  For "named field" items, the dissector *can*
construct the text representation, or it can let the core
Ethereal/Tethereal code do that.

A named field item contains, among other things, a reference to the
registered entry for the named field.

As per another message of mine:

	http://www.ethereal.com/lists/ethereal-dev/200206/msg00297.html

an option for generating CSV entries for packets could take, as a
specification, a comma-separated list of field names, such as

	ip.src,ip.dst,tcp.srcport,tcp.seq,tcp.len

and would, for each packet, report the "last" value of those fields in
the protocol tree for the packet.  (There is no guarantee that there
will be only one instance of a field in a protocol tree - no, not even
"ip.src" or "ip.dst".  Consider, for example, a capture with TCP atop IP
atop Frame Relay atop GRE atop IP atop Ethernet; no, that is not a
hypothetical example, I think Paul Ionescu had such a capture when he
was doing some of the Frame Relay dissector work.)

> Has anybody started to work on this already?

Not as far as I know.

> If somebody can point out
> what is needed, I can make a resource check whether I can support it. 

Well, you'd need to:

	pick a command-line option flag to use in Tethereal (if it were
	"-Q", for example - that's not a recommendation that you use
	"Q", it's just a letter Tethereal currently doesn't use - the
	command-line option would be something like

		-Q ip.src,ip.dst,tcp.srcport,tcp.seq,tcp.len

	pick some place in the menus to put it into Ethereal;

	for Tethereal, if that option is selected, arrange that a
	protocol tree be generated, and that the summary columns not be
	generated, when dissecting a packet;

	For Ethereal, have the menu item run a loop similar to the loop
	in "ph_stats_new()" in "proto_hier_stats.c", and, when
	processing a frame, arrange that a protocol tree be generated,
	and that the summary columns not be generated, when dissecting a
	packet;

	after constructing the protocol tree, scan the protocol tree,
	looking at all items, and when an item is found that matches one
	of the fields specified, save a pointer to that item, possibly
	overwriting the previous saved pointer found in the tree for
	that field;

	when the entire protocol tree has been processed, generate the
	CSV from the saved pointers, and print it.

If a packet doesn't have *all* the values, you'd either not print the
line, or leave the field empty in the CSV; I don't know which would be
considered "correct".