Re: [Ethereal-dev] Proposed change in the communication with the spawned capture process for Win32

[Guy Harris <gharris@xxxxxxxxx>]

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).