Date: Thu, 7 Dec 2000 23:55:36 -0800 From: Guy Harris <gharris@flashcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: Guy Harris <gharris@flashcom.net>, Dragos Ruiu <dr@kyx.net>, 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> In-Reply-To: <200012080738.eB87c9817756@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Dec 07, 2000 at 11:38:09PM -0800 References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207232722.A352@quadrajet.flashcom.com> <200012080738.eB87c9817756@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001207235536.D352>