From owner-freebsd-hackers Thu Dec 7 23:55:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:55:42 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by hub.freebsd.org (Postfix) with SMTP id 7360937B401 for ; Thu, 7 Dec 2000 23:55:42 -0800 (PST) Received: (cpmta 15886 invoked from network); 7 Dec 2000 23:55:41 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.81) with SMTP; 7 Dec 2000 23:55:41 -0800 X-Sent: 8 Dec 2000 07:55:41 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id XAA00585; Thu, 7 Dec 2000 23:55:36 -0800 (PST) (envelope-from gharris) Date: Thu, 7 Dec 2000 23:55:36 -0800 From: Guy Harris To: Matt Dillon Cc: Guy Harris , Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001207235536.D352@quadrajet.flashcom.com> References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207232722.A352@quadrajet.flashcom.com> <200012080738.eB87c9817756@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200012080738.eB87c9817756@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Dec 07, 2000 at 11:38:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 11:38:09PM -0800, Matt Dillon wrote: > It amounts to the same thing, since -w does nothing more then an > fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't > even double buffered. > > But I think the last poster had it right... if the bpf buffer size > was not changed from the default 4096, just about anything can interrupt > the packet flow. (If "the last poster" suggested cranking up BPF_MAXBUFSIZE, that was me.) libpcap's default in FreeBSD 3.4 is 32768, not 4096 - 4096 is the kernel's default, but libpcap overrides that - but that's still significantly lower than 1MB. I'm curious whether there's any compelling reason why you can't do an SIOCSBLEN on a device that's already been attached to an interface; perhaps it could do a "bpf_detachd()" if it was attached to an interface, and then do a "bpf_attachd()" after changing the size. However, that would work only on systems with a modified kernel; an alternative would be to add an variant of "pcap_open_live()" that took a buffer size argument, which could be made to work on existing BSD systems (as well as many other systems - including Windows :-)). That wouldn't help, though, unless BPF_MAXBUFSIZE were cranked up; it's 524288 in 4.x - that happened in delta 1.21: Revision 1.21 / (download) - annotate - [select for diffs], Sat Jan 15 19:46:12 2000 UTC (10 months, 3 weeks ago) by phk CVS Tags: RELENG_4_BP Branch point for: RELENG_4 Changes since 1.20: +2 -2 lines Diff to previous 1.20 (colored) |The hard limit for the BPF buffer size is 32KB, which appears too low |for high speed networks (even at 100Mbit/s this corresponds to 1/300th |of a second). The default buffer size is 4KB, but libpcap and ipfilter |both override this (using the BIOCSBLEN ioctl) and allocate 32KB. | |The following patch adds an sysctl for bpf_maxbufsize, similar to the |one for bpf_bufsize that you added back in December 1995. I choose to |make the default for this limit 512KB (the value suggested by NFR). so it might be interesting to retry the tests on a 4.x system, with the 32768 in pcap-bpf.c changed to 524288. It might also be interesting to try throwing a "setvbuf()" call into libpcap, to crank up the standard I/O buffer size (although on systems with small kernel buffers in the capture mechanism, a large write *might* take enough time that you could fill up and then overflow that buffer). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message