Greg Troxel wrote:
Michael Richardson <mcr%sandelman.ca@localhost> writes:"Darren" == Darren Reed <darrenr%netbsd.org@localhost> 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 timeout. e.g. if I do this in a script: tcpdump -w foo.cap icmp and host bar & tcpdumpjob=$! 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. Darren