tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Reliability issues with BPF

Greg Troxel wrote:
Michael Richardson <> writes:

"Darren" == Darren Reed <> writes:
    Darren> It seems like a relatively straight forward change:
    Darren> - if pcap loop has been broken because of EINTR
    Darren> and if pcap is working in blocking mode,
    Darren> set non-blocking mode and attempt to read any
    Darren> packets that are currently buffered.

so, in blocking mode, on NetBSD, why doesn't the pcap_loop() start up
each time thre is a packet received?  Is there a memory mapped shared
ring-buffer involved? (If so, can't the not-yet-signaled packets be
taken from the ring descriptors?)

My understanding from the last time I really dug into this was that
normally, read on bpf would return on the sooner of

  there is any data and a timeout (1s) has passed, or

  the buffer becomes full and bpf flips to the second buffer

But it seems not to work this way any more.

It still works that way.

The problem here is one of reliability of tcpdump exiting
with respect to what has been buffered in the kernel and
the expiration of the read

e.g. if I do this in a script:

tcpdump -w foo.cap icmp and host bar &
ping -c 3 bar
(assume ping returns 100% packets received)
kill -INT $tcpdumpjob

How many packets does "foo.cmp" have in it?
And more to the point, why should that answer not be 6?
(Lets assume that the only packets eligable to be caught
are the ICMP echo and recho reply.)
The existing implementation has no way to guarantee that
the number of packets in the file "foo.cmp" is 6 because
any packets buffered by BPF after the last 1 second timer
for tcpdump went off will be discarded by the SIGINT.

To say "insert sleep 1 before the kill" makes the script
dependent on internal functionality of tcpdump that appears
(to me) to be undocumented and thus not a reliable behavioural
aspect that can be relied upon. tcpdump could easily be
modified to wait two seconds and continue to work as documented
whilst now falling afoul of a script that only waits one second.


Home | Main Index | Thread Index | Old Index