Re: capturing on both interfaces simultaneously

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

On Dec 12, 2011, at 3:59 AM, David Laight wrote:

> The linux libpcap has a poll() in the 'memory mapped'
> kernel interface (in order to check for errors).
> If the application is using poll() this is an unnecessary
> system call.

The only way libpcap can infer that the application is using poll() is if it has put the pcap_t in non-blocking mode.  
libpcap used to avoid the poll() in that case, but that was causing applications to loop infinitely chewing up CPU; see 
the thread that starts at

        http://thread.gmane.org/gmane.network.tcpdump.devel/3937

That poll() is unnecessary in non-blocking mode only if the application isn't expecting libpcap to return errors, and 
is itself checking for those errors after the poll() call.  That would be the case only if the application knew it had 
to do that special Linux-specific stuff. 

> I also think that interface could defer freeing the last
> rx buffer until the request to read another packet.
> That would avoid the necessity of a buffer copy
> for applications that don't want to use callbacks.

That strategy was attempted by

        commit 54ef309e921c11a4e80cd7a26d9e25d30c833e14
        Author: Guy Harris <gharris@steve.local>
        Date:   Mon Mar 23 23:18:25 2009 -0700
    
            In memory-mapped mode, don't release the packet as soon as the callback
            finishes processing the packet; in some cases, such as pcap_next() and
            pcap_next_ex(), the packet data is expected to be available after the
            callback returns, and only discarded when the next packet is read.

in response to

        http://thread.gmane.org/gmane.network.tcpdump.devel/3571

and backed out by

        commit 703acf10e7b3a128c426937712cd12ae65e3b1e9
        Author: Guy Harris <gharris@steve.local>
        Date:   Fri Jul 3 14:37:06 2009 -0700   

            Not releasing a packet in Linux memory-mapped mode until we try to read
            the next packet breaks select().  Back those changes out; we'll have to
            fix the behavior of pcap_next* by making a copy of the packet.

in response to

        http://thread.gmane.org/gmane.network.tcpdump.devel/3937

and replaced by the current behavior in

        commit 34e950492a8b40673297d0888fafc4f94689cd29
        Author: Guy Harris <gharris@steve.local>
        Date:   Thu Jul 16 15:08:12 2009 -0700  

            When doing Linux mmapped capture:
    
                Allocate a buffer into which to copy a packet, and have the
                callback for pcap_next() and pcap_next_ex() copy to that buffer
                and return a pointer to that buffer; we can't return the packet
                data pointer passed to the callback, as, once the callback
                returns, that buffer can be overwritten, even before you read
                the next packet.

                Don't tweak filter programs passed into the kernel to return
                65535 on success - we don't have to, as we're not reading
                packets with recvfrom(), and we don't want to, as, if we return
                the actual snapshot length, the kernel will copy less data to
                the ring buffer.

                Truncate the packet snapshot length to the specified length, as
                we might not have a filter to do that.   

If you have a change that will eliminate the need for the copy *without* breaking Mike Kershaw's code, please 
contribute it.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.