Ethereal-dev: Re: [Ethereal-dev] [patch] Feature: read trace from a spawned process

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

From: Thomas Steffen <steffen.list.account@xxxxxxxxx>
Date: Wed, 17 Aug 2005 22:10:29 +0200
On 8/17/05, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> I'm no unix/pipe expert, but I've done several changes in the capture
> code recently.

Yes, I have noticed changes going on there :-). Thanks for your comments.

> First of all, this won't work with Windows, as "/bin/sh" is not
> available and probably other things may also not work on Windows like the
> 
> g_spawn_async_with_pipes() call.
>
> Even worse, this call isn't available in GLib 1.3, so it won't work on
> all unix like platforms we support either.

If somebody can point me to the "lowest common denominator", that
would help. I can also stick to POSIX calls on UNIX, but I have no
idea how to get the same done on Windows.

> In general, I don't know if it's really a good idea to add just
> *another* way to read from a pipe.

I hope that this feature would end these "small deltas". It is the
most general approach: you can capture, read, network - depending on
which program you spawn. Even live merging from several remote
locations should be possible (I do it, but it is a nonstandard
situation).

> In the end, what 's the difference to:
> 
> ssh -l root hostname tcpdump -filter -i eth0 | ethereal -k -i '-'

That did not work for me, maybe you need a *named* pipe. In bash I did use
 #  ethereal -k -i <(ssh -l root hostname tcpdump -filter -i eth0)
The capture buttons will not work. To start a new trace, you have to
quit ethereal, find and kill the subprocess (killall ssh is not all
that great), and then restart all with the same command line.

So the difference is useability. And it is rather significant, enough
to motivate we to write this patch.

Thomas