Re: unreported drops on dlpi

[Guy Harris <guy () netapp com>]

On Fri, Jan 24, 2003 at 02:05:41PM +0200, aviadl () gmx net wrote:
> Additionally, I think there's a point in allowing the user to set a
> capture parameter of "kernel buffer size", as in WinPcap; in the
> pcap-dlpi.c it should be the SBIOCSCHUNK flag, in pcap-snoop.c it should
> be setsockopt() of SO_RCVBUF.

...and in BPF it should be set with BIOCSBLEN; unfortunately, that has
to be done *before* the BPF device is attached to an interface, so the
kernel buffer size would have to be an argument to a new "open live"
routine, rather than an argument to a "set the buffer size" routine
called after you've opened a device.

There are some other reasons to have a new routine, such as:

        having an "open for capture" vs. "open for capture and sending"
        (and possibly vs. "open just for sending") flag, so that, if we
        implement a routine to send packets, an application could
        specify how it wants the interface opened - you might want to
        give more people read access to BPF devices than you give write
        access, so libpcap shouldn't *always* open for reading and
        writing;

        having an "I care whether things work correctly across a fork"
        flag - it's been claimed that the Linux memory-mapped capture
        buffer stuff has problems if the application forks (I guess it's
        a problem with using the buffer in the child), so we'd like to
        allow applications that Just Don't Care to open with "I don't
        care" and get the memory-mapped buffer if we add support for it,
        but still let applications that *do* care not to get it.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe