Re: forcing pcap_loop() failures

[Alexander Dupuy <alex.dupuy () mac com>]

rh wrote:

> After playing around with this for a while, the solution I've used is 
> to open two pcap_t * handles, set them non-blocking, and then call 
> pcap_dispatch() on each of them within a while(1) loop.


You really want to use select() (or poll() if your operating system 
doesn't support select()) instead of a CPU polling loop.  You can use 
pcap_get_selectable_fd() to get the underlying file descriptor on a Unix 
system (won't work on Windows, but neither will the "any" interface).  
Whenever select() indicates that a pcap fd can be read, call 
pcap_dispatch() to handle any packets, then return to the select() call.

> Second, for reasons I don't understand I seem to be losing packets on 
> the eth1_handle.  The traffic volume on eth1 is probably 10x that of 
> eth2, although at about 4 MB/s and the hardware I'm surprised to see this.


If you're still dropping packets once you eliminate the CPU busy loop, 
you may want to increase the buffer size, but fundamentally, the 
read-one-packet-at-a-time-from-packet-socket interface provided by 
libpcap on Linux is pretty poor.  If you are using libpcap on Linux, you 
want to use the mmap'd PACKET_RX_RING (or if you like modifying your 
kernel, PF_RING) interfaces.  These are not supported by the tcpdump.org 
or stock Linux libpcap libraries, but you can get a version of libpcap 
that does PACKET_RX_RING from http://public.lanl.gov/cpw/ or a PF_RING 
driver and libpcap patches from http://www.ntop.org/PF_RING.html

@alex

--
mailto:alex.dupuy () mac com

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.