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... _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
