tcpdump mailing list archives
Re: future direction for the libpcap API
From: Guy Harris <gharris () sonic net>
Date: Wed, 28 May 2003 11:25:29 -0700
On Wed, May 28, 2003 at 05:02:54PM +0200, Fulvio Risso wrote:
-----Original Message----- From: owner-tcpdump-workers () sandelman ottawa on ca [mailto:owner-tcpdump-workers () sandelman ottawa on ca]On Behalf Of Darren Reed Sent: lunedi 26 maggio 2003 15.39 To: tcpdump-workers () tcpdump org Subject: [tcpdump-workers] future direction for the libpcap API Looking through the API for libpcap, there appear to be a set of new convienience functions for Win32: int pcap_setbuff(pcap_t *p, int dim); int pcap_setmode(pcap_t *p, int mode); int pcap_sendpacket(pcap_t *p, u_char *buf, int size); int pcap_setmintocopy(pcap_t *p, int size); Is there any reason there shouldn't be an equivalent function for Un*x, no matter how simple or trivial ?ehmm... simple and trivial, that's the point.
Unfortunately, "pcap_setbuff()" isn't simple and trivial to implement: 1) you have to define what the "buffer size" is, or decide that the platform doesn't have such a notion (in which case the right thing to do is probably to make the call a no-op on that platform); 2) it's difficult, if not impossible, to implement on platforms with BPF, as the BPF buffer size can only be set *before* you've bound the BPF device to a network interface, but opening a device for capture binds the BPF device. 1) might be the socket buffer size on systems where you capture using a socket (Linux, Irix). 2) means we'd probably need "pcap_open_live_ex()" and "pcap_open_ex()" calls that take the buffer size as an argument. "pcap_setmode()" would be trivial to implement on platforms that support a WinPcap-compatible "statistical mode". Unfortunately, the only such platform is WinPcap, so.... "pcap_sendpacket()" is implementable (I have some untested code for it); however, you would really want "pcap_open_live_ex()" and additional flags for "pcap_open()", to let the application developer specify whether to open just for capturing, just for sending, or for capturing and sending. That'd be useful on systems using BPF, for example, as you might want to allow some users to capture packets but not send them - to do that, you'd just give them read but not write access to the BPF devices. Opening for reading and writing (as NetBSD does) means you can't do that - in order to capture, you'd need write access. (On platforms where there's no such distinction, the open mode flags would be ignored.) "pcap_setmintocopy()" applies only on platforms with a WinPcap-style "minimum amount of data in the kernel buffer that causes a read from the application to return"; that might be the case for Solaris, but I'd have to read the bufmod man page to be sure. On platforms with BPF, we could have a zero "size" argument turn "immediate mode" on and have a non-zero argument turn it off. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe
Current thread:
- future direction for the libpcap API Darren Reed (May 28)
- RE: future direction for the libpcap API Fulvio Risso (May 28)
- Re: future direction for the libpcap API Guy Harris (May 28)
- RE: future direction for the libpcap API Fulvio Risso (May 28)