Guy, Thank you! How I know that I can move on with faith that the next example, using pcap_dispatch() will work.
Sam On Mon, Dec 16, 2002 at 12:07:02PM -0800, Guy Harris wrote: > 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:[EMAIL PROTECTED]?body=unsubscribe
