Re: Possible New Option for Tshark?

[Craig Votava <craig.votava () alcatel-lucent com>]

Folks-

Many thanks for the replies, here are my responses:

> From: Stephen Fisher <steve () stephen-fisher com>
>
> On Thu, Oct 21, 2010 at 03:29:36PM -0500, Craig Votava wrote:
>
> > I wrote a Perl script that feeds pcap data to an instance of tshark
> > running in a child process, then takes the decoded output to present
> > to the user.
> >
> > The problem is that I don't know when tshark is done sending output
> > back to me.
>
> How about using "pdml" or "psml" with the -T option.

Stephen: Thanks for the suggestion! I actually played around with  
these a bit, and although it would work, I decided not to use it for  
performance reasons.

My tool is a real-time GUI for analyzing trace output. When the user  
clicks on a message, I want a selected portion of the ASCII tshark  
output (the meat of the message without the IP headers) slapped up in  
a window quickly. When I used pdml, it increased the lag time in  
getting the data up for the user. I'm guessing because it's more CPU  
intensive to have tshark format the data and then for my program to  
unformat it. The difference wasn't much, but it was noticeable, and  
annoying.

> ...especially given that the default ("-T text") output of TShark is  
> designed for humans, not programs, to read.  If your program can  
> read it, great, but if it's easier for it to read PSML or PDML....

Since the end result is to be displayed for humans, I'm hoping I can  
avoid the additional pdml->ascii iteration. It seems to me that a new  
tshark option to help me avoid this is a reasonable compromise. What  
are your thoughts?

> From: Mark Landriscina <mlandri1 () jhu edu>
>
> Using -T with pdml/psml would probably be the best approach if you  
> want text output. However, if that doesn't work for you, then you  
> could consider doing what some programs like SCAPY do. Save your  
> packets in a temp pcap file and pass the file name to your tshark  
> child process when you are spawning it.

Mark: Another good suggestion as well. This was how my first version  
was written, however the delay time for quickly slapping the output  
into the window for the user was too much. By holding a single tshark  
co-process up and running all the time, I get a very fast turnaround  
from supplying input and getting output. This really works well,  
except for knowing when to stop reading.

Since my first post, I've discovered a bunch of techniques for doing  
non-blocking reads on Windows. All of them seem more complicated to  
me, than just having tshark add an end-of-decoding indication to the  
ASCII output. Thoughts?

Thanks

-Craig

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe