tcpdump mailing list archives
Re: setting the initial ring size
From: Guy Harris <guy () alum mit edu>
Date: Wed, 9 Jan 2008 18:20:03 -0800
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 indicationon 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#sectionisbwhich 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.
Current thread:
- setting the initial ring size Abeni Paolo (Jan 07)
- Re: setting the initial ring size Andy Howell (Jan 07)
- Re: setting the initial ring size Guy Harris (Jan 09)
- Re: setting the initial ring size Abeni Paolo (Jan 10)
- Re: setting the initial ring size Guy Harris (Jan 10)
- Re: supporting extend 'open live capture' parametes [was: setting the initial ring size] Abeni Paolo (Jan 10)
- Re: supporting extend 'open live capture' parametes Guy Harris (Jan 10)
- Re: supporting extend 'open live capture' parametes Andy Howell (Jan 10)
- Re: supporting extend 'open live capture' parametes Guy Harris (Jan 10)
- Re: supporting extend 'open live capture' parametes Andy Howell (Jan 11)
- Re: supporting extend 'open live capture' parametes Michael Richardson (Jan 13)
- Re: supporting extend 'open live capture' parametes Guy Harris (Jan 13)
- Re: supporting extend 'open live capture' parametes Michael Richardson (Jan 13)
- Re: setting the initial ring size Guy Harris (Jan 09)
- Re: setting the initial ring size Andy Howell (Jan 07)