[Winpcap-users] capture filter complexity trade-off question

[Guy Harris]

On Aug 17, 2010, at 7:00 PM, Greg Hauptmann wrote:

> Any advice/guidance regarding pro's/con's for the following options:
> 
> a) minimise amount of packet matches by having a capture filter which
> has several "or" in it. Let say a filter that is something like
> "LocalHost and (ip 1 or ip 2 or ip3...ip10)", so say one "or" and 9
> "and"s.
> 
> b) simple capture filter, and then programmatically filter in code for
> all the matches (e.g. packet filter might include the localhost only
> filter, but not then try to filter out the 10 ip's)
> 
> I'm guess that option (a) should be the more optimal way to go,

That is almost certainly the case.

In both cases, you'll be filtering for all the IP addresses.  The filtering in the capture filter will be done by executing BPF pseudo-machine code or on-the-fly compiled code that compares IP addresses in the packet against the specified IP addresses.  If you're doing this on a platform where the BPF pseudo-machine code is interpreted, that will be less efficient than doing it in compiled machine code in the program, but probably not by a lot; if you're doing this on a platform where the BPF pseudo-machine code is translated into real machine code and executed, it will probably be about as efficient.

At least for 32-bit x86, sufficiently recent versions of WinPcap will, I think, translate it into real machine code and execute it (as will sufficiently-recent versions of FreeBSD, which picked up the translator from WinPcap); FreeBSD also wrote a 64-bit x86 (amd64/x86-64/x64/whatever you want to call it) version of the translator - I don't know offhand whether WinPcap picked that up or not.

A packet that doesn't match the WinPcap filter will be discarded by WinPcap before it's copied into WinPcap's kernel buffer, and thus also won't be copied into the userland buffer when the WinPcap library reads from that buffer; all other packets will be copied into WinPcap's kernel buffer, and then into the userland buffer.  The more packets that are copied into WinPcap's buffers, the more CPU time is spent copying those packets, *and* the faster WinPcap's kernel buffer fills up, and hence the faster it has to be emptied by the application calling the WinPcap library routines to read packets in order not to have the buffer get completely full before the next packet arrives - if the buffer is full when a packet arrives, the packet that arrives is discarded.

That means that a filter that discards more packets

	1) reduces the CPU requirement overall, even though it might take more CPU to execute the additional filter instructions

and

	2) reduces the chances that you'll drop packets.