Ethereal-dev: Re: [Ethereal-dev] Proposed change in the communication with the spawned capture
Francisco Alcoba (ML/EEM) wrote:
I've introduced a shared event between both processes, by which the
parent can tell the child to stop; the child then sets ld.go to false
and stops things orderly. I've put it both in capture_stop and in
kill_capture_child and it seems to work OK; however, the later uses
SIGTERM in unix and this seems to be more similar to an immediate
ExitProcess in the child,
Not exactly - SIGTERM delivers a signal that a process can capture, so
that it can clean up before exiting. SIGKILL is like
TerminateProcess(). I'm not sure there's a direct equivalent to SIGTERM
in Windows.
I'm thinking on using events -which I suppose would translate to
signals in unix-
Not exactly. Signals are delivered asynchronously; they're sort of like
interrupts. Events don't, as far as I know, cause a process to stop
whatever it's doing and call some procedure.
to be able to pause a capture, and to restart it -i.e.
to use a new temporary file- without killing and respawning the child
process, which takes quite long;
If the main loop of the capture process were blocked in a
MsgWaitForMultipleEvents() call, waiting for one of
user input;
packets arriving from the capture device;
an event;
the event could break the process out of the capture loop.
That's now how the *current* main loop works, however - and I think
versions of WinPcap prior to 3.0 had a bug where the call to get the
handle for the event on which to wait for packets to arrive didn't
return a valid handle on NT/2000/etc., so that technique couldn't be
used there. (I haven't tested 3.0 to see whether it's fixed - I think I
might have tried it with one of the betas, where it worked.)
Windows/WinPcap happens to be one of the platforms on which the
libpcap/WinPcap timeout timer exists, and starts when the read call is
made, rather than either not being implemented at all or being
implemented but starting when the first packet arrives ("implemented"
means "implemented by the underlying packet capture mechanism" rather
than "implemented by libpcap' - libpcap just passes the semantics of the
underlying packet capture mechanism's timer, if any, up to its caller).
This means that the main loop *can* poll an event, although it doesn't
respond immediately to the event firing - the recognition of the event
is delayed until the timer expires (which is probably at most 1 second
or so, so, in practice, it's acceptable).
however, I have been reading the thread
on security where the possibility of changing the capturer into a
smaller priviledged process has been commented, and this might make the
effort useless. Is there a decision on whether this is going to be
implemented?
No decision has been made one way or the other at this point. I think
it would probably be the right thing to do, although I don't know what
disadvantages might come up - or what the architecture would be.
One architecture might be to have the child process have *no* user
interface, and communicate with the main process over a pipe or other
interprocess communications channel. It'd be blocked in a main loop
waiting for
messages from the main process;
packets arriving from the capture device, *if* a capture is in progress;
and messages would tell it to start a capture (giving parameters such as
the interface on which to capture, the capture filter to use, the
snapshot length to use, etc.), stop a capture if one's running, etc..
While a capture is running, it'd send messages to the main process
giving packet counts - that'd require it to have the stuff currently
done by the "capture_" routines, doing a quick and *very* simple
analysis of the lower-layer protocols. It'd write to the capture file.
This is somewhat similar to the architecture currently used for "Update
list of packets in real time" captures, except that the subprocess
currently maintains the packet count window.
In such an architecture, the scheme for stopping the capture would be
similar to the one I described above. It would, again, depend on being
able to get an event handle from WinPcap on Windows (which might, or
might not, work with the DAG card support); it would also depend on
being able to get from libpcap on UN*X a descriptor on which it could do
a "select()" or "poll()", which is possible on *most* UN*Xes, but:
due to a fix to one bug and the lack of a fix to another, it's not
possible on FreeBSD 4.3 or 4.4 - it's possible on earlier and later
versions;
it might, or might not, be possible on AIX;
it's not possible when capturing on DAG cards on Linux or FreeBSD (the
drivers, unfortunately, don't support "select()"/"poll()", although I
suspect it could be made to do so).
