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.
