Re: Losing BPF's

[Guy Harris <guy () alum mit edu>]

Jon Steel wrote:
> I did some more digging and I think Ive narrowed the problem down a bit
> more. It does appear to be a kernel issue. pcaps off the hook for today.
>
> For those interested, the problem occurs for the following reasons: When
> you call open() on OpenBSD it does not lock the file unless you tell it
> to. This means multiple pcap connections can get a file descriptor for
> the same /dev/bpfN file.

When you call open() on a special file (such as /dev/bpfN) on OpenBSD, 
does it call the driver's open routine, even if the device is already open?

If so, then that open routine:

int
bpfopen(dev_t dev, int flag, int mode, struct proc *p)
{
        struct bpf_d *d;

        /* create on demand */
        if ((d = bpfilter_create(minor(dev))) == NULL)
                return (ENXIO);
        /*
         * Each minor can be opened by only one process.  If the requested
         * minor is in use, return EBUSY.
         */
        if (!D_ISFREE(d))
                return (EBUSY);

        /* Mark "free" and do most initialization. */
        d->bd_bufsize = bpf_bufsize;
        d->bd_sig = SIGIO;

        D_GET(d);

        return (0);
}

would fail with EBUSY if the device is already open.

sys_open() (for the open() system call), calls vn_open() on all opens, 
which calls VOP_OPEN() on all opens.  For special files, that should go 
to spec_open(), which appears to call the driver open routine 
(*cdevsw[maj].d_open) for all opens.

Thus, there should be no need to lock the device; the BPF driver should, 
in effect, be doing it for you.  That's the way BPF has worked on BSD 
for quite a while (since it was first introduced, I think).  Libpcap 
explicitly requires that, as do other users of BPF - they keep opening 
successive BPF devices until they get one that they can successfully open.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.