Wireshark-dev: Re: [Wireshark-dev] one possible way to speed up filtering
From: Martin Visser <[email protected]>
Date: Thu, 19 Mar 2009 21:54:13 +1100

I know it was only an example, but your "DNS is only over UDP" is a bad one. DNS can use TCP for any query/response, either when the response is bigger than a 512byte PDU, or when doing AXFR zone transfers.

But in princple the idea of preventing redundant dissection is great. I often see wireshark spending time performing dissection when, at least to my mind, it is probably redundant.

Regards, Martin

[email protected]

2009/3/18 yami <[email protected]>
Hi dev,

I have implemented a prototype to speed up interactive filtering. The key idea is to reuse previous display information. (Is there anyone interested in this idea?)

For example, a user filters 'udp' first, then he tries to filter 'dns'. Since we know that only packets passed 'udp' filter string have the possibility to pass 'dns', there is no need to dissect packets not passed the 'udp' filter.

This could be a big gain, if the capture is large, but UDP packets occupy only a small portion of it.

In my current implementation, if in the second filtering, the user inputs 'udp && dns', Wireshark will find that 'udp' has already been filtered, so if a packet did not passed 'udp', Wireshark will not dissect it again.

The above is only the simplest case. In general this is a Boolean Satisfiability [1] problem. Assume a new display filter, say D, contains previous applied filters S1, ..., Sn. We know that S1...Sn are subtrees of D's syntax tree.

And for packet P, if it passed Si then assigned Bi to 1, otherwise 0, so we get B1,...,Bn; then we can generate a boolean _expression_, say EXP, for D with its subtrees S1,...,S2 replaced by B1,...,Bn.

If EXP could never be true, then P will not pass D (we know this without dissecting/filtering).
If !(EXP) could never be true, then P will pass D.
If the above two are satisfied, we should dissect/filter P.

[1] http://en.wikipedia.org/wiki/Boolean_satisfiability_problem
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:[email protected]?subject=unsubscribe