Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Controlling Tshark output format

From: "Douglas Pratley" <Douglas.pratley@xxxxxxxxxx>
Date: Mon, 12 Feb 2007 13:22:42 -0000
Hi

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx 
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Gerald Combs
> Sent: 08 February 2007 01:12
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Controlling Tshark output format
> 
> Would it make more sense to extend the current -T flag e.g.
> 
>   -Tfields,ip,udp,tcp.srcport
> 
> instead?  This would tie the output spec directly to the "fields"
> format.  It might be useful to be able to restrict the fields 
> in the "pdml", "ps", and "text" formats as well.

That would certainly save on using up another switch. Two possible
problems:
a) I've also added a set of sub-options under the "-E" switch that
control the format of the output:

-Tfields -e udp.port -E header=y[es] -E quote=d[ouble] -Eseparator=,

(There were a number of emails about CSV output recently that make it
clear that some users need power to express output in ways that don't
conflict with their locale).
I can't see a good way to wrap that up in the -Tfields... string
(particularly as "," would be a common choice of separator).

b) I didn't want to restrict the possible names of fields. So far, all
the ones in Wireshark are "sensible" strings, but I can't find any code
that restricts them, so they might contain commas, spaces, etc. The -e
<field> syntax should cope with anything other than embedded quotes
without any extra work. If there is a rule (written or unwritten) that
keeps field names to be e.g. alphanumeric + '_' then this problem would
go away.

If (b) is just me being paranoid, and if anyone can come up with a good
way to encapsulate both field names and the sub-options in one string
following -Tfields, then I could adjust the code before sending out the
patch.

Cheers

Doug

> 
> > 
> > On 2/1/07, *Douglas Pratley* <Douglas.pratley@xxxxxxxxxx 
> > <mailto:Douglas.pratley@xxxxxxxxxx>> wrote:
> > 
> >     Hi all
> > 
> >     I'm looking at implementing a feature from the Wishlist that we
> >     would like as well: the ability to control the output 
> of tshark e.g.
> > 
> >     tshark -Tfields -e ip - e udp - e tcp.port
> > 
> >     This new format would produce a line per packet, but 
> would do full
> >     dissection. "ip" would dump out the whole representation for the
> >     "ip" field.
> > 
> >     For the command line parameters, I'm planning to enforce both an
> >     output type switch (-Tfields) and at least one field entry (-e).
> >     This leaves open the possibility of combining "-e" with other
> >     verbose options (pdml, verbose text) if people want it.
> > 
> >     I've picked -e because it was free and the example in 
> the Wishlist
> >     uses it. I don't think it's particularly appropriate, 
> but ones that
> >     might have been are gone.
> > 
> >     I also prefer to have multiple fields as multiple -e statements
> >     rather than one with a quoted, space separated list e.g 
> -e "ip udp
> >     tcp.port"; largely because it saves having to add 
> another layer of
> >     (admittedly trivial) parsing code.
> > 
> >     It would be good to also have options controlling how 
> this works in
> >     detail:
> >     (a) An optional first "header" line listing the selected fields
> >     (b) An option to control the separator (I'm defaulting to tab
> >     because that doesn't tend to come up in Wireshark output)
> > 
> >     but I don't want to clutter the options list any more. 
> Can anyone
> >     think of an elegant way to do this?
> > 
> >     I'd also like to hijack the -c option to only read in 
> the first "n"
> >     packets of a file, rather than just for live capture as 
> at the moment.
> > 
> >     Comments / suggestions?
> > 
> >     Cheers
> > 
> >     Doug
> > 
> > 
> > 
> > 
> >     This message should be regarded as confidential. If you have
> >     received this email in error please notify the sender 
> and destroy it
> >     immediately.
> >     Statements of intent shall only become binding when confirmed in
> >     hard copy by an authorised signatory. The contents of 
> this email may
> >     relate to dealings with other companies within the 
> Detica Group plc
> >     group of companies.
> > 
> >     Detica Limited is registered in England under No: 1337451.
> > 
> >     Registered offices: Surrey Research Park, Guildford, Surrey, GU2
> >     7YP, England.
> > 
> > 
> >     _______________________________________________
> >     Wireshark-dev mailing list
> >     Wireshark-dev@xxxxxxxxxxxxx <mailto:Wireshark-dev@xxxxxxxxxxxxx>
> >     http://www.wireshark.org/mailman/listinfo/wireshark-dev
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> 
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>