Wireshark · Wireshark-dev: Re: [Wireshark-dev] tshark using dumpcap almost there - please defer any capture related development

[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

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...