filter efficiencies

Guess I should not have written an off the hip question. My original was more of a concept question on how does the code of wireshark process filters. You got me on details, which I am usually a stickler on :) So let me rewrite my original question :)

A) (conditional test #1) && (conditional test #2)

B) (conditional test #3) * where B) provides the same answer as A)

Not being a hard core coder it seems to me that logically test B) would be twice as fast as A) so where you can take the time to optimize filters. Think of a script which you have setup to pre-parse capture files and generate a report before you even open the capture file for the first time. Filters run inside repeating scripts which can be optimized to run faster should, imho.

I assume this question has been asked before but I am unable to locate an answer. There is a Performance page on the Wiki but it does not address this question.

I realize this question was geared more for Wireshark display filters, but for capture filters, you can directly compare them by having tcpdump or dumpcap generate the bpf code if you specify the -d option. For example, if you run these two commands, you can see that they produce the exact same resulting bpf code:

dumpcap -i 2 -f "tcp[13]==6" -d
dumpcap -i 2 -f "tcp[tcpflags]==tcp-syn|tcp-rst" -d

Here's the output in either case:

(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 10
(002) ldb      [23]
(003) jeq      #0x6             jt 4    jf 10
(004) ldh      [20]
(005) jset     #0x1fff          jt 10   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldb      [x + 27]
(008) jeq      #0x6             jt 9    jf 10
(009) ret      #262144
(010) ret      #0

If you generate the bfp code, it can help you determine if one capture filter is more efficient than another or if they differ in any way.

Here's the output in either case

Not surprising, given that, in effect, "tcpflags" is a macro for "13" , "tcp-syn" is a macro for "0x02", "tcp-rst" is a macro for "0x04", and libpcap's BPF compiler's optimizer evaluates some expressions at compile time.

For display filters, there's a program dftest, which is part of the Wireshark source, and may be installed if Wireshark is; if, for example, you run dftest 'tcp.flags.syn == 1 && tcp.flags.reset == 1', it prints

Filter: "tcp.flags.syn == 1 && tcp.flags.reset == 1"

Constants:
00000 PUT_FVALUE        1 <FT_BOOLEAN> -> reg#2
00001 PUT_FVALUE        1 <FT_BOOLEAN> -> reg#3
Instructions:
00000 READ_TREE         tcp.flags.syn -> reg#0
00001 IF-FALSE-GOTO     7
00002 ANY_EQ            reg#0 == reg#2
00003 IF-FALSE-GOTO     7
00004 READ_TREE         tcp.flags.reset -> reg#1
00005 IF-FALSE-GOTO     7
00006 ANY_EQ            reg#1 == reg#3
00007 RETURN

which is the code that’s interpreted at run time by the display filter code. So you could use dftest on the two filter expressions to see what test instructions are generated.

Whether (conditional test #3) generates fewer instructions than (conditional test #1) && (conditional test #2) and, if so, how many fewer instructions are generated, depends on what the three conditional tests are.

Not surprising, given that, in effect, “tcpflags” is a macro for “13” , “tcp-syn” is a macro for “0x02”, “tcp-rst” is a macro for “0x04”,

Right, I was just illustrating the fact that tcp-syn|tcp-rst is equivalent to 6, and not 12, as Antacus originally wrote in the question. If the names are used instead of the number, then you can be assured of the correct value being used, so it’s generally better to use the names.

And thanks for mentioning dftest. I sometimes forget about it because for some unknown reason, it has never been packaged with the Wireshark Windows installer, and Windows is the platform I generally use.

And to compare Guy’s dftest output for the “tcp.flags.syn == 1 && tcp.flags.reset == 1” filter, here’s the dftest output for tcp.flags == 6:

Filter: “tcp.flags == 6”

Constants:
00000 PUT_FVALUE        6 <FT_UINT16> -> reg#1
Instructions:
00000 READ_TREE         tcp.flags -> reg#0
00001 IF-FALSE-GOTO     3
00002 ANY_EQ            reg#0 == reg#1
00003 RETURN

So clearly this filter is [slightly] more efficient.

I think Guy’s dftest portion of his comment should be the answer to this question.