Re: setting the initial ring size

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

On Jan 7, 2008, at 4:05 PM, Andy Howell wrote:

> A 'capabilities' API could be useful. It would allow the developer  
> to take advantage of platform specific features in a generic way.  
> Capabilities might include:
>
>         Can get/set receive buffer size
>         Has nmap
>         Has pf_ring
>         Set filter flushes packets
>         Has extended statistics
>         Can set direction

Some of those are "platform-specific" in the sense that they pertain  
to particular features of particular platforms, e.g. PF_RING.  I'm not  
sure how you'd "take advantage" of PF_RING, though - once that's  
checked in, libpcap will automatically use it if you have it, and not  
use it if you don't; why would an application need to know whether the  
platform has PF_RING or not?

Others would be "platform-specific" in that some platforms have them  
but not others - and we already have that; some platforms support  
"batching" of incoming packets, and thus support the timeout argument  
to pcap_open_live(), and others don't support batching and ignore the  
timeout argument.  (No, the timeout argument isn't a "only wait this  
long for packets to arrive" argument; on Solaris, for example, the  
timer doesn't start until the first packet arrives - it's intended to  
keep you from waiting forever for a *full* batch, but not intended to  
keep you from waiting forever for a packet to arrive at all.   
Applications that assume that, on all platforms, the timer starts when  
you ask for packets are buggy.)

"Set filter flushes packets" shouldn't be the capability - "a call to  
set the filter *without* flushing packets" should be the capability;  
we support a "set filter" that flushes packets on *all* platforms, as  
that's what you want, on all platforms, for the case where you do  
pcap_open_live() and then pcap_setfilter() (e.g., that's what tcpdump/ 
WinDump and Wireshark/TShark want).  An *additional* call to let you  
set the filter without flushing packets would either

        1) not exist

or

        2) exist but return an error indication

on platforms that don't have that capability.  The first of those  
options has the advantage that an application that *required* that  
capability wouldn't even *compile* on platforms that don't have it, so  
false hopes would be dashed ASAP. :-)  However, given that libpcap  
supports multiple capture mechanisms on some platforms (e.g., the  
native capability and capture on DAG cards), it might be the case that  
you don't know whether "set filter without flushing packets" is  
available without knowing the device on which you're capturing, in  
which case it has to return an error at run time.

"Set receive buffer size at open time" could be implemented on most if  
not all platforms - including platforms using BPF; it would require a  
new "open a live capture" call, but that might be useful for other  
purposes (e.g., to request monitor mode on 802.11 devices).  The  
ability to set it after opening couldn't be provided particularly  
conveniently on platforms using BPF (it would involve closing the BPF  
device, re-opening it, setting the buffer size, re-binding it to the  
appropriate device, installing the appropriate filter, blah blah  
blah), but I don't know whether it'd be useful if you had the ability  
to set it at open time.

I'm not sure what "has mmap" (which I assume is what you meant by "has  
nmap") would be used for, just as I'm not sure what "has PF_RING"  
would be used for - on platforms supporting a mapped capture buffer  
(and where it provided some advantage), it would presumably be used on  
a live-capture open if available and not used if not available.

If by "extended statistics" you mean extending what pcap_stats()  
returns, then what we really want is a call that returns something  
similar to the contents of pcap-NG's Interface Statistics Block:

        http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionisb

which means that it can be extended without changing any binary  
interfaces (it would either return a pointer to a buffer allocated and  
attached to the pcap_t, or allocate a buffer, fill it in, and return a  
pointer to it).

For "can set direction", we already have a call for that on all  
platforms; it just returns an error if it's not supported.

It still might be useful for an application to be able to query  
whether, for example, you can set the direction, so it can fail very  
early on.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.