Red Hat Bugzilla – Bug 52654
Tcpdump get spurious packets before kernel filter kicks in
Last modified: 2008-05-01 11:38:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; OSF1 V4.0 alpha)
Description of problem:
When running tcpdump using a kernel filter on a busy network, I see several
packets that do not match my filter at the beginning of the dump. After
several of these, the filter kicks in and the output is correct.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Machine A is 192.168.0.1
Machine B is 192.168.0.2
Machine C is 192.168.0.3
0. make sure your kernel supports socket filters
1. on machine A, start a ping flood to another machine "ping -f
2. on machine A, start a tcpdump filtering traffic to machine C "tcpdump
3. you will see several of the icmp echo and echo responses from machine B,
then only traffic to machine C
Actual Results: I see several packets to Machine B in the dump
Expected Results: I should not see packets from Machine B in the dump,
only packets to and from machine C
This issue occurs due to the interaction in libpcap and the kernel
implementation of filters. When a PF_PACKET socket is created, it is bound
into the network and starts receiving packets. Packets are placed upon its
queue for pickup via recvfrom(). libpcap then binds the socket to an
interface, and then sets the filter on the socket. None of these actions
call skb_queue_purge(), which means that packets that were put in the queue
before the filter was set remain in the queue and are picked up by libpcap,
and hence tcpdump.
If you use the PACKET_RX_RING extensions, skb_queue_purge() is called, and
you will only see filtered packets. Also, if kernel filtering is not
available, the user BPF filter is called for each packet received, and this
problem will not surface.
fixed in tcpdump-3.6.2-8
If curious, this should already be fixed in tcpdump.org HEAD branch:
(new set_kernel_filter function).
I wonder when the next version is coming out...