Richard van der Hoff wrote:
Hi Ulf,
Ulf Lamping wrote:
Hi List!
I've mostly finished the work to reimplement tshark to call dumpcap
instead of pcap directly. This implements the long awaited better
privilege seperation for tshark.
Huzzah! This is excellent news.
Some things I've already noticed that still needs a solution:
1) Read filters won't really work as they did before.
dumpcap don't know anything about display filter code (by definition),
so it can't handle the read filter by itself and simply writes all
packets that goes through the capture filter. With the new
implementation, I don't have a good idea to solve this in tshark - BTW
we have the same problem in Wireshark already today.
I don't really understand what the problem is here: it's the whole
reason we have both capture filters and read filters - capture filters
are more efficient but less flexible.
Should we redefine "read filters" as only being useful/usable when
reading from a file (not when capturing)?
I suppose I can see a use case, though, where someone needs to do a lot
of capture-time filtering so they have a capture filter _and_ a read
filter to limit what gets into *shark to limit memory usage.
But... Why can't *shark do read filter processing (after reading from
the pipe or whatever other source)? I suppose I should go take a look
at Wireshark to see...
