Ethereal-dev: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
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).
