On Oct 11, 2015, at 5:00 PM, liu wen <caonimagongl...@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
