[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] future direction for the libpcap API
From:       Guy Harris <gharris () sonic ! net>
Date:       2003-05-28 18:25:29
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]