Re: why does pcap_dispatch return 0?

[Guy Harris <guy () alum mit edu>]

On Oct 11, 2015, at 5:00 PM, liu wen <caonimagongling () gmail com> wrote:

> int pcapfd;
> pcap_t *pcap_handle;
> struct event  pcap_ev;
>
> pcap_handle = create_pcap("eth0", NONBLOCKING);
> pcapfd = pcap_get_selectable_fd(pcap_handle);
> if(pcapfd<0){
> perror("pcap_get_selectable_fd() failed!\n");
> exit(1);
> }
>
> if (setnonblock(pcapfd) == -1) return -1;

You should be using pcap_setnonblock(pcap_handle) instead.  There is *no* guarantee that setting non-blocking mode on 
the selectable file descriptor will actually put the pcap_t into a non-blocking mode, as there is no guarantee that 
libpcap will be performing read-like system calls on any file descriptor (from "eth0", I'm guessing this is Linux, in 
which case it probably will *NOT* be doing read-like calls - read(), recvmsg(), whatever - on the descriptor; it will, 
instead, be sharing a memory-mapped buffer with the kernel, and, if the buffer is empty, will be doing a select() call 
to wait for packets, unless the pcap_t was put into non-blocking mode, in which case it won't bother with the select() 
call).

> then I run the program on host A and send packets from host B, meanwhile I
> use a tcpdump to capture packets on A  (tcpdump -i eth0  port 8000 )
> the tcpdump can capture the packet, but in the program,  pcap_dispatch()
> returns 0 when it is called for first time and the second time (so I get to
> consecutive 0, "pcap_dispatch() returns 0", also collect_pkt() was not
> invoked), what is wrong? (when it is called for the thrid time, it returns
> 1)

The pcap_dispatch() man page says:

       pcap_dispatch()  returns  the  number  of packets processed on success;
       this can be 0 if no packets were read from  a  live  capture  (if,  for
       example,  they  were discarded because they didn't pass the packet fil-
       ter, 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) ...

With BPF (as you have on *BSD, OS X, Solaris 11, and AIX), and with sufficiently recent versions of the Linux kernel 
and libpcap, the platform supports a read timeout, so the event mechanism libevent is using (*any* mechanism it would 
use) may get wakeups from the kernel even if there are no packets available to read.

You should just treat a return of 0, in a live capture, as a "false alarm, no packets available, keep looking" 
indication, and not worry about it.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers