tcpdump mailing list archives
Re: pcap_next returns "Didn't grab packet"
From: Guy Harris <guy () netapp com>
Date: Mon, 16 Dec 2002 12:07:02 -0800
On Sat, Dec 14, 2002 at 02:41:29PM -0500, Sam Carleton wrote:
I know that pcap works because I have compiled snort and have been able to get that to work fine. I was wondering if anyone might have some thoughts on why the testpcap1.c sample will not work.
Because it was written by somebody who thought "the whole world runs Linux". :-) "pcap_next()" returns a null pointer if "pcap_dispatch()" returns a value <= 0. To quote the current CVS version of the libpcap man page: pcap_dispatch() is used to collect and process packets. cnt specifies the maximum number of packets to process before returning. This is not a minimum number; when reading a live capture, only one bufferful of packets is read at a time, so fewer than cnt packets may be processed. A cnt of -1 processes all the packets received in one buffer when reading a live capture, or all the packets in the file when reading a ``savefile''. ... ... The number of packets read is returned. 0 is returned if no packets were read from a live capture (if, for example, they were discarded because they didn't pass the packet filter, or if, on platforms that support a read timeout that starts before any packets arrive, the timeout expires before any packets arrive, or if the file descriptor for the capture device is in non-blocking mode and no packets were available to be read) or if no more packets are available in a ``save- file.'' A return of -1 indicates an error in which case pcap_perror() or pcap_geterr() may be used to display the error text. so it can return 0 if, for example: 1) on a platform where packet filtering is done in user mode rather than the kernel, the kernel hands a buffer full of packets to libpcap but none of them pass the filter; 2) on a platform that supports a read timeout that starts before any packets arrive, and that causes the read/recvfrom/getmsg/whatever from the kernel to return when the timeout expires even if no packets have arrived, no packets arrive within the timeout interval. (Those are a more detailed and complete description of the first two cases mentioned in the parenthetical note in the second paragraph I cited from the man page.) NetBSD (along with the other BSDs) is a platform that supports a read timeout that starts before any packets arrive, and that causes the read from the kernel to return when the timeout expires even if no packets have arrived. Linux is not. Therefore, on *some* Linux systems (those running a 2.2 or later kernel, and with the socket filter mechanism compiled in, so that packet filtering is done in the kernel), "pcap_dispatch()" isn't likely to return 0, so "pcap_next()" is unlikely to return NULL, and the sample program is more likely to work. On BSD systems - and Linux systems without socket filter support, or with an old libpcap that doesn't support that mechanism - "pcap_next()" is more likely to return NULL, although it's much more likely to do so on BSD systems. Unfortunately, "pcap_next()" is a somewhat crappy API, and doesn't indicate to its caller why "pcap_dispatch()" returned 0, so there's not much that can be done to fix testpcap1.c without changing it to use "pcap_dispatch()" rather than "pcap_next()". - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe
Current thread:
- pcap_next returns "Didn't grab packet" Sam Carleton (Dec 15)
- Re: pcap_next returns "Didn't grab packet" Guy Harris (Dec 16)
- Re: pcap_next returns "Didn't grab packet" Sam Carleton (Dec 16)
- Re: pcap_next returns "Didn't grab packet" Guy Harris (Dec 17)
- Re: pcap_next returns "Didn't grab packet" Guy Harris (Dec 16)