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

["packet steve" <packetsteve@xxxxxxxxxxx>]

I have good luck with perl/awk post-processing.
A simple CSV scheme is pretty limited, and may confuse people using it.

In addition to the duplicates caused by layers of encapsulations: lists with 
varying lengths may share the same field name, some protocols (e.g., SCTP) 
will stuff multiple messages into a single frame.   There are quite a few 
text-only items in dissectors.

Would it help to describe a generalized "-O" format that reflected the 
encapsulations?  E.g.,
   Ethernet/IP/UDP/GTP/ip.src, Ethernet/IP/UDP/GTP/ip.dst
and use
   */ip.src, */ip.dst  [or just ip.src, ip.dst]
for those cases where encapsulations aren't a concern.  With some thought we 
could also handle multiple field names or lists.  Something like
   proto.field(1), proto.field(3)
or even
   proto.field(*), proto.field($)

Just a thought.



> From: Guy Harris <guy@xxxxxxxxxx>
> To: "Roger Kalden (EED)" <roger.kalden@xxxxxxxxxxxxxxx>
> CC: "'ethereal-dev@xxxxxxxxxxxx'" <ethereal-dev@xxxxxxxxxxxx>
> Subject: [Ethereal-dev] Re: [Ethereal-users] ethereal to csv
> 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".
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com