Ethereal-dev: Re: [Ethereal-dev] Feature proposal: read capture from a spawned process

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

From: Guy Harris <gharris@xxxxxxxxx>
Date: Mon, 01 Aug 2005 10:16:59 -0700
Thomas Steffen wrote:
Ethereal should be able to spawn a child process, and read libpcap
formated capture data from the stdout of that process.
It can already do the latter, but you have to manually create a FIFO 
file and run the other process with its standard output redirected to 
the file; the former is a convenience feature.
1. Do we need a checkbox "spawn child process", or do we want a magic
character like '|' at the start of the file name to trigger this
feature? For security reasons I would propose the former, although it
is more work.
I'm not sure why the former is more secure - I don't see why clicking a 
checkbox is more safe than typing a "|".  We already do special hacks to 
implement the "read from a FIFO" feature.
(BTW, with this feature, is the "read from a FIFO" feature still useful?)

Another question, though, is which of those is better from a UI perspective. "|" would probably be very obvious to those experienced with UN*X at the command line (although one might argue that the "|" would belong at the *end* of the line, as you're piping *from* the command *to* Ethereal), but it might not be as familiar to Windows users (although maybe command-line users *might* think of it, given that Windows also supports piping on the command line) or to UN*X users less familiar with the command line.
2. I imagine there would be problems with buffering. Any easy way to
solve them? ssh -t usually works for me, but from a technical
perspective that seems very inefficient.
Buffering is an issue on the send side, so I'm not sure there's any way 
to solve it in Ethereal.  It could be solved *for the case where 
Tethereal is the only program in the pipeline* by adding a flag to 
Tethereal to cause it to "fflush()" the standard output for each packet 
or each batch of packets - the latter requires a change to the main loop 
to use pcap_dispatch() rather than pcap_loop(), so that batch boundaries 
can be seen.  A similar option could be added to tcpdump.
Netcat appears to have no option to control *its* buffering.