On Apr 9, 2004, at 2:17 PM, Darren Reed wrote:

> Really?  So....hmmm....this isn't what I was expecting.  I should have
> paid closer attention to what the code was doing rather than trusting
> it was setting it and working.  You might have suspected that this code
> was originally written on Windows and has been ported back to Unix and
> given that the function is present, no consideration was given to 
> whether
> or not the code actually did anything.

The function isn't even present on tcpdump.org's libpcap for UN*Xes; 
did you use a modified version of libpcap?  (If so, perhaps they *have* 
figured out a way to set the buffer size after the BPF device is bound 
to an interface, although I don't see one from looking at the kernel 
BPF code; if they have, we'd be interested in adding that to 
tcpdump.org's libpcap.)

> No (see previous comment).  I think what I'm going to do, now I read
> this, is create:
>
> pcap_open_live2(device, snaplen, bufsize, promisc, ms, ebuf)
>
> and have pcap_open_live() call it with bufsize == 0 or something
> and...  see patch below.  Qualifies as a dirty hack but maybe it's
> good enough? I've only implemented pcap_open_live2() for BPF just
> as "proof of concept."

Sounds good as a "proof of concept"; my plans are to add an API that 
adds an attribute/value list of open options, so that

	1) new options can be added over time as necessary (e.g., perhaps 
adding "monitor mode", channel, etc. options for 802.11) without having 
to change the API;

	2) the API doesn't acquire a lot of parameters, especially ones that 
need special "don't care" values (so that you could do an open without 
explicitly requesting a buffer size);

	3) there can be another API indicating when options are supported for 
a particular device or platform (so that, for example, GUI applications 
can disable UI elements that let you set parameters that aren't 
supported for a given device).

It'll also support an open flags argument (a superset of WinPcap's 
"pcap_open()" flags) and an authentication argument for remote capture.

BTW, is there any reason why libpcap shouldn't just set the buffer size 
to the maximum on BPF systems?  Is there a concern that it'd chew up 
too much wired-down memory if lots of applications that don't need a 
large buffer (e.g., because they're capturing with a filter that 
discards most packets) run with one?