Ethereal-dev: Re: [Ethereal-dev] Feature proposal: read capture from a spawned process
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.
