Re: Buffer size question

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

On Oct 18, 2004, at 3:04 PM, Alexander Dupuy wrote:

> Guy Harris writes:
> > Unfortunately, given that, on systems with BPF, you cannot change the  
> > buffer size after a BPF device has been bound to a network interface,  
> > "pcap_setbuff()" is unimplementable on those systems, so it's not a  
> > candidate for libpcap.
>
> I didn't realize it was possible to set the buffer size with BPF; but  
> indeed it is, and I see that it will even support sending up multiple  
> packets from the kernel (on my FreeBSD 5.2 box at least), making the  
> buffer size of some actual significance.  Odd that the requirement  
> that the BIOCSBLEN ioctl be performed before BIOCSETIF isn't  
> documented anywhere, but I'll take your word for it (and even if this  
> restriction were eliminated, other systems might have it).

It's documented in the 4.4-Lite bpf(4) man page at

	http://www.freebsd.org/cgi/man.cgi? 
query=bpf&apropos=0&sektion=0&manpath=4.4BSD+Lite2&format=html

where it says

       BIOCSBLEN (u_int)
                 Sets the buffer length for reads on  bpf  files.
                 The  buffer  must  be  set  before  the  file is
                 attached to an interface with BIOCSETIF.

The various BSDs probably say the same thing (OS X definitely does).

> > Some mechanism to supply that information at open time, whether it's  
> > an additional argument (which I think is the right long-term answer),  
> > a change to libpcap so that it doesn't reduce the buffer size below  
> > the default (which libpcap 0.8 already does), or an  
> > environment-variable
>
> I agree that an additional argument is the right long-term answer, but  
> it does introduce API compatibility issues.

Well, yes, to the extent that a new API would be introduced, and  
programs that need to work with older versions of libpcap can't use  
that new API.

Including such an argument at the time the new API is introduced  
obviously doesn't introduce compatibility issues for that API. :-)   
(I'm actually thinking of an attribute/value list for various open  
options in the API, so that additional "arguments" can be introduced as  
desired without requiring API changes.)

> The functions we added are:
>
> int pcap_getbufsize(pcap_t *p, char *errbuf);
> int pcap_setbufsize(pcap_t *p, int bufsize, char *errbuf);
>
> both functions return -1, with error buffer filled in (if non-NULL) on  
> error
>
> pcap_getbufsize returns buffer size on success
> pcap_setbufsize returns 0 on success
>
> Although we haven't implemented it, this can be generalized to accept  
> a NULL pcap_t *p to get/set the default used for newly pcap_open()d  
> handles, thereby allowing the BPF case to be supported as well.

That's probably OK as a medium-term fix.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.