The BPF(4) man page:
still implies that you have separate /dev/bpfN devices in one place;
still says only Ethernet, SLIP, and PPP are supported, and that no network types with variable-length headers (such as 802.11) are supported;
says that EIO, not EINVAL, is returned if you do a read() with a buffer size other than the one specified with BIOCSBLEN;
has some stylistic glitches;
doesn't document BIOCGDLTLIST, BIOCSDLT, BIOCSRSIG or BIOCGRSIG;
doesn't document the standard ioctls that apply to a BPF device;
says the bf_len field of a "struct bpf_program" and the "k" field of a BPF instruction are signed;
says the "k" field of a BPF instruction, and the bh_caplen and bh_datalen fields of the BPF per-packet header, are u_long, rather than bpf_u_int32.
Fix: Patch attached with submission follows:
While we're at it, we might as well remove
Since packet data is in network byte order, applications should use
the byteorder(3) macros to extract multi-byte values.
because, in fact, not all packet data *is* in network byte order (SMB
fields, for example, are little-endian).
I've attached an updated patch.
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped