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

["Francisco Alcoba (ML/EEM)" <francisco.alcoba@xxxxxxxxxxxx>]

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

What I meant is that maybe SIGTERM should be read as "stop working, don't worry to update statistics, check ringubffer files, etc, because I want you to exit immediately... that is, close things and do ExitProcess-"; the difference with TerminateProcess would basically be the possibility for the process to enforce consistence on open files, etc. if needed. Anyway, I don't think that is too different from what it does now.

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

So, if I understant it correctly, it should be possible to

 - in Windows, use events that are read because the timeout in WinPcap works
 - in anything else, use signals because they would take the process out of the capture -what happens when the signal handler? does the process continue after the select?

That is, if the bug in WinPcap is corrected, the loop would wait for events for user input, parent events or captured packets; if it is not, it would wait for events for user input or parent events, and run select periodically for captured packets.

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

(cut text)

This seems to be a complex issue that might take a while to implement, so I think it might be good to have at least the pause functionality implemented before. Anyway, most of the modifications would be to the user interface; the capture process, other than setting up an event/signal and check for it, needs few changes -I've got it working associated to a different button, and it seems to work OK-. Do you consider it interesting -i.e. would it be included in the code if I manage to get it working?-.