tcpdump slowed down by... its own filter?

Question

Do long BPF filters slow down tcpdump?

I replay a packet trace where all the packets have ttl=k and wait for ICMP messages back. What I've been noticing is that if I use the following filter (on eth0):

(ip and ip[8]=$k and src host $myAddress) or (icmp and dst host $myAddress and icmp[0]=11)

...I always miss 20-30 packets among the sent packets, whereas if I just do:

ip

... and then do the exact above filtering offline on the capture file, I find all the packets I had sent.

Is this a known behaviour?

Answer 1

If tcpdump is not fast enough to pop out captured packets from the queue, the kernel could drop some of them.

Look at the "XXXX packets dropped by kernel" message at the end of the dump to see if effectively some of them is lost.

Ensure to add the -n option to the command line. This will avoid DNS resolving and it will speed up a little (depending on your network)