Wireshark-dev: Re: [Wireshark-dev] tshark: drop features "dump to stdout" and "read filter"
From: Michael Tuexen <[email protected]>
Date: Tue, 9 Oct 2007 09:21:03 +0200
Hi Ulf,

a question inline...

Best regards
On Oct 9, 2007, at 8:50 AM, Ulf Lamping wrote:

Hi List!

I had a look at the tshark buildbot test problems and found two things
that are currently not working as before. But let me shortly explain
what's going on "under the hood" with the "new" privilege seperation:

Just as Wireshark is doing it already for some time, tshark now also use
dumpcap to capture stuff (to seperate the "potential dangerous"
dissection from the "root required" capturing). tshark calls dumpcap
with a set of command line options (capture interface, capture file
name, ...) and establishes a pipe to dumpcap. Now dumpcap captures
packets into a temporary file, a named file or some ringbuffer files and
notices tshark events through a pipe, e.g. a new file was opened, some
packets rushed in, ...

Now the two problems in the buildbot test are:

a) dumping to stdout (using -w -)
Dumping to stdout will mix up with the pipe (standard-)output, so this
cannot work as before. BTW: Wireshark cannot capture to stdout for the
same reason (or am I missinformed here?).

Solution: to dump to stdout, use dumpcap - it's build for that purpose. Document that dumping to stdout doesn't work with tshark / Wireshark and
prevent "-w -" command line option.

b) read filter
dumpcap doesn't know anything about display filter syntax - to gain
I agree, no display filters in dumpcap.
better security (that's explicitly the difference between tshark and
dumpcap!). So dumpcap cannot filter out that stuff and will dump
everything it get's to the output file. As the resulting capture file
contains "all packets" now, everything filtered now is a "sort of"
display filter anyway - so the concept of a read filter doesn't really
work here ...
What is a read filter? I think we should continue to support the
capture filters.
Solution: Drop read filters completely, they don't really fit in the
concept of privilege seperation. Document the change and prevent the
according command line option(s).

Please note: I'm not argueing against the usefullness of both options,
but they don't fit into the idea of privilege seperation and the current implementation of it. So I don't see a good way to "re-"implement them ...
Regards, ULFL
Wireshark-dev mailing list
[email protected]