Re: [tcpdump-workers] buffer size question
rupesh gautam wrote: why changing buffer size is unimplementable on systems with bpf. It's not *completely* unimplementable. It can, however, not be done after the BPF device has been bound to a network interface, which means that it cannot be done after pcap_open_live(). I don't know why the buffers are allocated at attach time and why they reject attempts to change the buffer size after that rather than, in effect, temporarily detaching the interface from the device (so that no packets are transferred into the buffer that's being freed), freeing the old buffers, allocating new buffers, and reattaching the interface (the detaching and reattaching could be done by setting a reallocation in progress flag and ignoring BPF tap calls if the flag is set), other than perhaps because it was simpler to do so and because code can set the buffer size before binding (even though libpcap doesn't support that). Why libpcap doesn't support that is another matter. LBL's libpcap tried setting it to 32K, but it did have an XXX comment this should be a user-accessible hook, so they apparently thought it should. and does packet drop depends upon packet filter??- A packet filter will discard packets before putting them into the buffer, so if you have a packet filter, it might reduce the number of packet drops by discarding packets deemed uninteresting before they get put into the buffer. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Buffer size question
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=bpfapropos=0sektion=0manpath=4.4BSD+Lite2format=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.
Re: [tcpdump-workers] Buffer size question
On Mon, Oct 18, 2004 at 04:37:41PM -0700, Guy Harris wrote: 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.) I think that's a great idea. The promisc option could then use the same method. Bruce Simpson posted (here and to freebsd-net) a patch to add an ioctl to control timestamp behaviour which would also be nicely handled with an attribute/value list scheme. Ed Maste Sandvine Inc. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Buffer size question
shouldn't we have upper/lower boundary checks for such a buffer ? i.e. minbuffer 1.5K maxbuffer 128K So would you propose just returning an error from pcap_open_live if the obtained buffer size is less than minbuffer? Something like if PCAP_MAXBUFFER environment var is set and 0, start with that value else if ioctl(BIOCGBLEN) is 32K, use that else start at 32K do divide-by-two loop to find a workable size if PCAP_MINBUFFER environment var is set, return error if ioctl(BIOCGBLEN) returns less than the environment var What do you think of this? Ed Maste Sandvine Inc. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Buffer size question
- Original Message - From: Guy Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:45 AM Subject: Re: [tcpdump-workers] Buffer size question Ed Maste wrote: 1) Add a new pcap API function pcap_set_bufsize that can be used to set the size used for following pcap_open_live calls (by setting a libpcap global variable). The global variable is a bit ugly. If you're going to have API changes... 2) Add a new function like pcap_open_live that adds a buffer size argument. http://www.tcpdump.org/lists/workers/2000/msg01358.html ...you might as well do that, as there are other reasons for a new API. ...like pcap_setbuff(), as implemented in WinPcap... http://winpcap.polito.it/docs/docs31beta3/html/group__wpcapfunc.html#a29 Have a nice day GV 3) Use an environment variable (PCAP_BUFFER_MAX?) to set the initial trial buffer size. Existing applications could even use a larger size without recompiling. 4) Do a BIOCGBLEN ioctl before trying the initial size. If the size returned is greater than the initial size, just avoid BIOCSBLEN. On FreeBSD I've got a sysctl debug.bpf_bufsize that sets the default buffer size, but it has no effect for libpcap. The disadvantage is that the same size gets used for all pcap users, which might be undesirable. One of those might also be useful. In fact, libpcap 0.8[.x] already does 4). Adding 3) might be useful to override the default for existing programs. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Buffer size question
...like pcap_setbuff(), as implemented in WinPcap... ...and which I already know about. ...and also, which I mentioned in my original email: Basically provide the same functionality as pcap_setbuff from winpcap, but it has to be called before opening the bpf dev. or an environment-variable based mechanism (which is probably an OK short-term answer, if just boosting the default isn't acceptable - a very large default runs the risk of running out of kernel address space, which I've managed to do on at least one OS using BPF; that caused a network configuration daemon not to be able to work, which left my machine unusable). That's exactly the case I was concerned about -- I might want a large buffer for an IDS or similar, while also having a DHCP client on a different interface using bpf with a standard, smaller buffer. Anyway, anoncvs at cvs.tcpdump.org isn't working for me: cvs [login aborted]: recv() from server cvs.tcpdump.org: EOF I'll download one of the nightly tars and try out the environment variable idea. Ed Maste Sandvine Inc. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
