Joerg Mayer wrote:
Ulf,
will ethereal and tethereal now use dumpcap by default?
ethereal will use it (without a choice)
tethereal won't use it for now. I'm planning to add support to it later
However, I'm just glad that it works now. Lot's of capturing code
cleanup were needed, and tethereal already uses a lot of the same code
as dumpcap does. So the next steps should be easier to do.
It doesn't seem to do so on my system:
root 3856 10.6 2.9 68188 30916 pts/5 S+ 13:33 0:02 ethereal
root 3859 5.1 1.9 35264 19984 pts/5 S+ 13:33 0:00 ethereal-capture -i eth0 -f
and tethereal doesn't even have a child process.
Dumpcap definitely got built and installed.
Hmmm, the ethereal-capture task won't be used any longer, you should see
dumpcap instead.
Sure that you don't use an installed Ethereal and not the SVN one?!?
Another thing: Now that this gets production quality, should be stay
with the name or use something more fancy (like inca or incato;
intelligent capture tool).
I don't think dumpcap is quite intelligent, it's still quite dumb in my
eyes ;-)
I don't have heard a real good name till now, so I'll stuck with
dumpcap. Any good ideas still welcome.
One last thing (which comes way too late::-) isn't this tool
already too powerful? Maybe a stupid capturing tool without the ability
to write files would have been safest. Just cpaturing to stdout or
something similar and everything else still done in (t)ethereal.
This makes it much, much more likely that we get packet drops.
dumpcap is modeled after the previous Ethereal two task model and I
think it's a quite good trade off between safety and performance.
Regards, ULFL
