Ethereal-dev: Re: [Ethereal-dev] Split the capture-child into it's own program?!?
Ethereal development <ethereal-dev@xxxxxxxxxxxx> schrieb am 17.11.05 11:02:17:
>
> ...and perhaps usable as a quick stand-alone capture program
> independently from Ethereal.
That's exactly what I had in mind ;-)
>
> - main loop of Ethereal doesn't have to include waiting on the capture
> device, which is somewhat tricky (e.g., GTK+'s/GLib's main loop uses
> poll() on UN*X, but BPF devices aren't supported by poll() in Mac OS X
> 10.4[.x] - they're only supported by select(), and even that has the
> annoying problem found at least in older versions of other BSDs that
> require a timeout in the select). Pipes support select() and poll(); on
> Windows, you can *probably* do a WaitForMultipleEvents() to select on
> them (the GLib/GTK+ main loop uses WaitForMultipleEvents() or
> MsgWaitForMultipleEvents() on Windows).
I would think that's already done in the capture child, just like it's done today. Ethereal main program only has to handle with the capture file and some input from the signal_pipe.
We might keep the dependency to GLib/GTK, so not much changes in this regard (at least for now).
>
> > - we might be able to drop the requirement of GTK completely for the
> > capture child (when the capture info window isn't needed)
>
> Do the capture window stuff in the main program, and have the capture
> child just send packet counts on a pipe (or shared memory?) to the main
> program.
I would prefer the shared memory approach. However, we can think about this later.
> Note that GTK+ refuses to run set-UID (because you can crack
> set-UID GTK+ programs by getting it to load *your* code in theme
> engines, etc.).
>
Hmm, didn't know this! So we have to remove the GTK dependencies at some point in time ...
So the first step would be to carve out the things we have today into a whole new capture application (and to keep the task simple, change as little as possible). Next would be to change/cleanup the Ethereal main.c (and probably other files) and really use this new tool for Ethereal capturing.
This will be a "huge" task of it's own, without even changing a lot of the existing code, so let's do it step by step.
What about the name for this new program? ethdump? ethcapture? ethereal-cap? ethereal-capture? dump2cap? dumpcap?
IMHO dumpcap would be a nice name ...
Regards, ULFL
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131
