Wireshark-dev: Re: [Wireshark-dev] tshark: drop features "dump to stdout" and "read filter"
Ulf Lamping wrote on 10/09/2007 02:50 AM:
> 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.
But we could still dump to a file, right? If you're proposing removing
-w entirely and pushing this usage to dumpcap, that's not a great
solution for me. I don't understand why this would be difficult to
accomplish with privilege sep. Couldn't dumpcap just handle the
capture, and tshark write the dump file? What output pipe does tshark
have that will get messed up?
We frequently use -w and -R to capture specific packet streams (with
filters not supported by pcap, like -R mpls.label==300; even filters
supported by pcap work better with read filters, like vlan.id==100,
which pcap doesn't support if the VLANs are inside MPLS encap).
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).
Yikes! This would really hurt. As above, we use read filters almost
exclusively. We would at least need to be able to do this:
dumpcap -i eth2 > packets.cap
tethereal -r packets.cap -R mpls.label==300 -w filtered.cap
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 ...
Is there a problem keeping read filters for tshark as used in my
example above, where we're just processing a dump file? There's no
security issue there, as tshark doesn't need root privileges when it's
not attaching to a socket, right?
Bottom line: I cannot really live without read filters, and it would
be awfully inconvenient to switch to dumpcap instead of tshark for
dumping a file -- not a show-stopper (users can eventually be
trained), but a pain. This really seems to be more about syntax than
whether or not it's possible to retain -w and -R, isn't it? The new
privsep architecture leaves the capture to the privileged dumpcap,
pipes all of the packets to tshark, which should be able to implement
read filters and output dumping without privileges.
Thanks,
--kirby
