ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: [Wireshark-dev] tshark: drop features "dump to stdout" and "read filter"

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 09 Oct 2007 08:50:59 +0200
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 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 ...

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