From owner-freebsd-net Sat Sep 21 13:17:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1DAA37B401 for ; Sat, 21 Sep 2002 13:17:08 -0700 (PDT) Received: from web14207.mail.yahoo.com (web14207.mail.yahoo.com [216.136.173.71]) by mx1.FreeBSD.org (Postfix) with SMTP id B51AB43E42 for ; Sat, 21 Sep 2002 13:17:08 -0700 (PDT) (envelope-from neelnatu@yahoo.com) Message-ID: <20020921201708.69253.qmail@web14207.mail.yahoo.com> Received: from [66.171.82.5] by web14207.mail.yahoo.com via HTTP; Sat, 21 Sep 2002 13:17:08 PDT Date: Sat, 21 Sep 2002 13:17:08 -0700 (PDT) From: Neelkanth Natu Subject: Re: pcap & bpf To: Petri Helenius , freebsd-net@freebsd.org In-Reply-To: <3D8C35E2.803199B3@he.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, --- Petri Helenius wrote: > (I'm sending a copy here since I'm running this on FreeBSD and got > no reply so far from the tcpdump folks) > > Function pcap_open_live in pcap-bpf.c contains the code snippet below. > > To me, this does not make too much sense, because: > - if v is too big to be accommodated (either by configuration or > resources, BIOCSBLEN will fail. However the code ignores the return > code BIOCSBLEN can fail only if the the bpf is already attached to an interface. Otherwise the code sandwiches the requested value of bufsize between bpf_maxbufsize and BPF_MINBUFSIZE. So there is no way this could really "fail". > - it then proceeds to BIOCSETIF which will succeed either with the > bufsize of 32768 or whatever is default in the OS. On the other hand it is possible for BIOCSETIF to fail in bpf_allocbufs(). And the pcap code does check for ENOBUFS. So what the code snippet is doing is entirely reasonably. Making the initial bufsize requested by pcap user-configurable, might be a solution to your problem. best Neel > > Suggestions: > - Do not touch the buffer size (at least without giving the option > to specify the size) > - If some operating systems really need touching the buffersize, > do BIOCGBLEN first to figure out what you got and in any case > don't make the bufsize smaller than it was > (reason: doing highspeed capture with 32k buffer is futile) > > I staticly linked with patched library with large buffers and > it works happily, before that the system dropped a few thousand > packets a minute. > > Pete > > > /* > * Try finding a good size for the buffer; 32768 may be too > * big, so keep cutting it in half until we find a size > * that works, or run out of sizes to try. > * > * XXX - there should be a user-accessible hook to set the > * initial buffer size. > */ > for (v = 32768; v != 0; v >>= 1) { > /* Ignore the return value - this is because the call fails > * on BPF systems that don't have kernel malloc. And if > * the call fails, it's no big deal, we just continue to > * use the standard buffer size. > */ > (void) ioctl(fd, BIOCSBLEN, (caddr_t)&v); > > (void)strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name)); > if (ioctl(fd, BIOCSETIF, (caddr_t)&ifr) >= 0) > break; /* that size worked; we're done */ > > if (errno != ENOBUFS) { > snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCSETIF: %s: %s", > device, pcap_strerror(errno)); > goto bad; > } > } > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message