1 .\" Copyright (c) 2007 Seccuris Inc.
2 .\" All rights reserved.
4 .\" This software was developed by Robert N. M. Watson under contract to
7 .\" Redistribution and use in source and binary forms, with or without
8 .\" modification, are permitted provided that the following conditions
10 .\" 1. Redistributions of source code must retain the above copyright
11 .\" notice, this list of conditions and the following disclaimer.
12 .\" 2. Redistributions in binary form must reproduce the above copyright
13 .\" notice, this list of conditions and the following disclaimer in the
14 .\" documentation and/or other materials provided with the distribution.
16 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
19 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" Copyright (c) 1990 The Regents of the University of California.
29 .\" All rights reserved.
31 .\" Redistribution and use in source and binary forms, with or without
32 .\" modification, are permitted provided that: (1) source code distributions
33 .\" retain the above copyright notice and this paragraph in its entirety, (2)
34 .\" distributions including binary code include the above copyright notice and
35 .\" this paragraph in its entirety in the documentation or other materials
36 .\" provided with the distribution, and (3) all advertising materials mentioning
37 .\" features or use of this software display the following acknowledgement:
38 .\" ``This product includes software developed by the University of California,
39 .\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
40 .\" the University nor the names of its contributors may be used to endorse
41 .\" or promote products derived from this software without specific prior
42 .\" written permission.
43 .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
44 .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
45 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
47 .\" This document is derived in part from the enet man page (enet.4)
48 .\" distributed with 4.3BSD Unix.
57 .Nd Berkeley Packet Filter
61 The Berkeley Packet Filter
62 provides a raw interface to data link layers in a protocol
64 All packets on the network, even those destined for other hosts,
65 are accessible through this mechanism.
67 The packet filter appears as a character special device,
69 After opening the device, the file descriptor must be bound to a
70 specific network interface with the
73 A given interface can be shared by multiple listeners, and the filter
74 underlying each descriptor will see an identical packet stream.
76 Associated with each open instance of a
78 file is a user-settable packet filter.
79 Whenever a packet is received by an interface,
80 all file descriptors listening on that interface apply their filter.
81 Each descriptor that accepts the packet receives its own copy.
83 A packet can be sent out on the network by writing to a
86 The writes are unbuffered, meaning only one packet can be processed per write.
87 Currently, only writes to Ethernets and
92 devices deliver packet data to the application via memory buffers provided by
94 The buffer mode is set using the
96 ioctl, and read using the
99 .Ss Buffered read mode
102 devices operate in the
103 .Dv BPF_BUFMODE_BUFFER
104 mode, in which packet data is copied explicitly from kernel to user memory
108 The user process will declare a fixed buffer size that will be used both for
109 sizing internal buffers and for all
111 operations on the file.
112 This size is queried using the
114 ioctl, and is set using the
117 Note that an individual packet larger than the buffer size is necessarily
119 .Ss Zero-copy buffer mode
121 devices may also operate in the
122 .Dv BPF_BUFMODE_ZEROCOPY
123 mode, in which packet data is written directly into two user memory buffers
124 by the kernel, avoiding both system call and copying overhead.
125 Buffers are of fixed (and equal) size, page-aligned, and an even multiple of
127 The maximum zero-copy buffer size is returned by the
130 Note that an individual packet larger than the buffer size is necessarily
133 The user process registers two memory buffers using the
135 ioctl, which accepts a
137 pointer as an argument:
147 is a pointer to the userspace address of the first buffer that will be
150 is a pointer to the second buffer.
152 will then cycle between the two buffers as they fill and are acknowledged.
154 Each buffer begins with a fixed-length header to hold synchronization and
155 data length information for the buffer:
157 struct bpf_zbuf_header {
158 volatile u_int bzh_kernel_gen; /* Kernel generation number. */
159 volatile u_int bzh_kernel_len; /* Length of data in the buffer. */
160 volatile u_int bzh_user_gen; /* User generation number. */
161 /* ...padding for future use... */
165 The header structure of each buffer, including all padding, should be zeroed
166 before it is configured using
168 Remaining space in the buffer will be used by the kernel to store packet
169 data, laid out in the same format as with buffered read mode.
171 The kernel and the user process follow a simple acknowledgement protocol via
172 the buffer header to synchronize access to the buffer: when the header
177 hold the same value, the kernel owns the buffer, and when they differ,
178 userspace owns the buffer.
180 While the kernel owns the buffer, the contents are unstable and may change
181 asynchronously; while the user process owns the buffer, its contents are
182 stable and will not be changed until the buffer has been acknowledged.
184 Initializing the buffer headers to all 0's before registering the buffer has
185 the effect of assigning initial ownership of both buffers to the kernel.
186 The kernel signals that a buffer has been assigned to userspace by modifying
188 and userspace acknowledges the buffer and returns it to the kernel by setting
194 In order to avoid caching and memory re-ordering effects, the user process
195 must use atomic operations and memory barriers when checking for and
196 acknowledging buffers:
198 #include <machine/atomic.h>
201 * Return ownership of a buffer to the kernel for reuse.
204 buffer_acknowledge(struct bpf_zbuf_header *bzh)
207 atomic_store_rel_int(&bzh->bzh_user_gen, bzh->bzh_kernel_gen);
211 * Check whether a buffer has been assigned to userspace by the kernel.
212 * Return true if userspace owns the buffer, and false otherwise.
215 buffer_check(struct bpf_zbuf_header *bzh)
218 return (bzh->bzh_user_gen !=
219 atomic_load_acq_int(&bzh->bzh_kernel_gen));
223 The user process may force the assignment of the next buffer, if any data
224 is pending, to userspace using the
227 This allows the user process to retrieve data in a partially filled buffer
228 before the buffer is full, such as following a timeout; the process must
229 recheck for buffer ownership using the header generation numbers, as the
230 buffer will not be assigned to userspace if no data was present.
232 As in the buffered read mode,
237 may be used to sleep awaiting the availability of a completed buffer.
238 They will return a readable file descriptor when ownership of the next buffer
239 is assigned to user space.
241 In the current implementation, the kernel may assign zero, one, or both
242 buffers to the user process; however, an earlier implementation maintained
243 the invariant that at most one buffer could be assigned to the user process
245 In order to both ensure progress and high performance, user processes should
246 acknowledge a completely processed buffer as quickly as possible, returning
247 it for reuse, and not block waiting on a second buffer while holding another
252 command codes below are defined in
257 #include <sys/types.h>
258 #include <sys/time.h>
259 #include <sys/ioctl.h>
274 the following commands may be applied to any open
277 The (third) argument to
279 should be a pointer to the type indicated.
280 .Bl -tag -width BIOCGETBUFMODE
283 Returns the required buffer length for reads on
288 Sets the buffer length for reads on
291 The buffer must be set before the file is attached to an interface
294 If the requested buffer size cannot be accommodated, the closest
295 allowable size will be set and returned in the argument.
296 A read call will result in
298 if it is passed a buffer that is not this size.
301 Returns the type of the data link layer underlying the attached interface.
303 is returned if no interface has been specified.
304 The device types, prefixed with
309 .Pq Li "struct bpf_dltlist"
310 Returns an array of the available types of the data link layer
311 underlying the attached interface:
312 .Bd -literal -offset indent
319 The available types are returned in the array pointed to by the
321 field while their length in u_int is supplied to the
325 is returned if there is not enough buffer space and
327 is returned if a bad address is encountered.
330 field is modified on return to indicate the actual length in u_int
331 of the array returned.
338 field is set to indicate the required length of an array in u_int.
341 Changes the type of the data link layer underlying the attached interface.
343 is returned if no interface has been specified or the specified
344 type is not available for the interface.
346 Forces the interface into promiscuous mode.
347 All packets, not just those destined for the local host, are processed.
348 Since more than one file can be listening on a given interface,
349 a listener that opened its interface non-promiscuously may receive
350 packets promiscuously.
351 This problem can be remedied with an appropriate filter.
353 The interface remains in promiscuous mode until all files listening
354 promiscuously are closed.
356 Flushes the buffer of incoming packets,
357 and resets the statistics that are returned by BIOCGSTATS.
359 .Pq Li "struct ifreq"
360 Returns the name of the hardware interface that the file is listening on.
361 The name is returned in the ifr_name field of
365 All other fields are undefined.
367 .Pq Li "struct ifreq"
368 Sets the hardware interface associated with the file.
370 command must be performed before any packets can be read.
371 The device is indicated by name using the
376 Additionally, performs the actions of
380 .Pq Li "struct timeval"
381 Sets or gets the read timeout parameter.
383 specifies the length of time to wait before timing
384 out on a read request.
385 This parameter is initialized to zero by
387 indicating no timeout.
389 .Pq Li "struct bpf_stat"
390 Returns the following structure of packet statistics:
393 u_int bs_recv; /* number of packets received */
394 u_int bs_drop; /* number of packets dropped */
399 .Bl -hang -offset indent
401 the number of packets received by the descriptor since opened or reset
402 (including any buffered since the last read call);
405 the number of packets which were accepted by the filter but dropped by the
406 kernel because of buffer overflows
407 (i.e., the application's reads are not keeping up with the packet traffic).
413 based on the truth value of the argument.
414 When immediate mode is enabled, reads return immediately upon packet
416 Otherwise, a read will block until either the kernel buffer
417 becomes full or a timeout occurs.
418 This is useful for programs like
420 which must respond to messages in real time.
421 The default for a new file is off.
424 .Pq Li "struct bpf_program"
425 Sets the read filter program used by the kernel to discard uninteresting
427 An array of instructions and its length is passed in using
428 the following structure:
432 struct bpf_insn *bf_insns;
436 The filter program is pointed to by the
438 field while its length in units of
439 .Sq Li struct bpf_insn
445 for an explanation of the filter language.
446 The only difference between
452 performs the actions of
458 .Pq Li "struct bpf_program"
459 Sets the write filter program used by the kernel to control what type of
460 packets can be written to the interface.
468 .Pq Li "struct bpf_version"
469 Returns the major and minor version numbers of the filter language currently
470 recognized by the kernel.
471 Before installing a filter, applications must check
472 that the current version is compatible with the running kernel.
473 Version numbers are compatible if the major numbers match and the application minor
474 is less than or equal to the kernel minor.
475 The kernel version number is returned in the following structure:
483 The current version numbers are given by
484 .Dv BPF_MAJOR_VERSION
486 .Dv BPF_MINOR_VERSION
489 An incompatible filter
490 may result in undefined behavior (most likely, an error returned by
492 or haphazard packet matching).
496 Sets or gets the receive signal.
497 This signal will be sent to the process or process group specified by
504 Sets or gets the status of the
507 Set to zero if the link level source address should be filled in automatically
508 by the interface output routine.
509 Set to one if the link level source
510 address will be written, as provided, to the wire.
511 This flag is initialized to zero by default.
515 These commands are obsolete but left for compatibility.
521 Sets or gets the flag determining whether locally generated packets on the
522 interface should be returned by BPF.
523 Set to zero to see only incoming packets on the interface.
524 Set to one to see packets originating locally and remotely on the interface.
525 This flag is initialized to one by default.
526 .It Dv BIOCSDIRECTION
527 .It Dv BIOCGDIRECTION
529 Sets or gets the setting determining whether incoming, outgoing, or all packets
530 on the interface should be returned by BPF.
533 to see only incoming packets on the interface.
536 to see packets originating locally and remotely on the interface.
539 to see only outgoing packets on the interface.
540 This setting is initialized to
546 Set or get format and resolution of the time stamps returned by BPF.
548 .Dv BPF_T_MICROTIME ,
549 .Dv BPF_T_MICROTIME_FAST ,
550 .Dv BPF_T_MICROTIME_MONOTONIC ,
552 .Dv BPF_T_MICROTIME_MONOTONIC_FAST
553 to get time stamps in 64-bit
558 .Dv BPF_T_NANOTIME_FAST ,
559 .Dv BPF_T_NANOTIME_MONOTONIC ,
561 .Dv BPF_T_NANOTIME_MONOTONIC_FAST
562 to get time stamps in 64-bit
567 .Dv BPF_T_BINTIME_FAST ,
568 .Dv BPF_T_NANOTIME_MONOTONIC ,
570 .Dv BPF_T_BINTIME_MONOTONIC_FAST
571 to get time stamps in 64-bit
576 to ignore time stamp.
577 All 64-bit time stamp formats are wrapped in
580 .Dv BPF_T_MICROTIME_FAST ,
581 .Dv BPF_T_NANOTIME_FAST ,
582 .Dv BPF_T_BINTIME_FAST ,
583 .Dv BPF_T_MICROTIME_MONOTONIC_FAST ,
584 .Dv BPF_T_NANOTIME_MONOTONIC_FAST ,
586 .Dv BPF_T_BINTIME_MONOTONIC_FAST
587 are analogs of corresponding formats without _FAST suffix but do not perform
588 a full time counter query, so their accuracy is one timer tick.
590 .Dv BPF_T_MICROTIME_MONOTONIC ,
591 .Dv BPF_T_NANOTIME_MONOTONIC ,
592 .Dv BPF_T_BINTIME_MONOTONIC ,
593 .Dv BPF_T_MICROTIME_MONOTONIC_FAST ,
594 .Dv BPF_T_NANOTIME_MONOTONIC_FAST ,
596 .Dv BPF_T_BINTIME_MONOTONIC_FAST
597 store the time elapsed since kernel boot.
598 This setting is initialized to
603 Set packet feedback mode.
604 This allows injected packets to be fed back as input to the interface when
605 output via the interface is successful.
608 direction is set, injected outgoing packet is not returned by BPF to avoid
610 This flag is initialized to zero by default.
612 Set the locked flag on the
615 This prevents the execution of
616 ioctl commands which could change the underlying operating parameters of
618 .It Dv BIOCGETBUFMODE
619 .It Dv BIOCSETBUFMODE
621 Get or set the current
623 buffering mode; possible values are
624 .Dv BPF_BUFMODE_BUFFER ,
625 buffered read mode, and
626 .Dv BPF_BUFMODE_ZBUF ,
627 zero-copy buffer mode.
629 .Pq Li struct bpf_zbuf
630 Set the current zero-copy buffer locations; buffer locations may be
631 set only once zero-copy buffer mode has been selected, and prior to attaching
633 Buffers must be of identical size, page-aligned, and an integer multiple of
641 If buffers have already been set for this device, the ioctl will fail.
644 Get the largest individual zero-copy buffer size allowed.
645 As two buffers are used in zero-copy buffer mode, the limit (in practice) is
646 twice the returned size.
647 As zero-copy buffers consume kernel address space, conservative selection of
648 buffer size is suggested, especially when there are multiple
650 descriptors in use on 32-bit systems.
652 Force ownership of the next buffer to be assigned to userspace, if any data
653 present in the buffer.
654 If no data is present, the buffer will remain owned by the kernel.
655 This allows consumers of zero-copy buffering to implement timeouts and
656 retrieve partially filled buffers.
657 In order to handle the case where no data is present in the buffer and
658 therefore ownership is not assigned, the user process must check
662 .It Dv BIOCSETVLANPCP
663 Set the VLAN PCP bits to the supplied value.
667 now supports several standard
669 which allow the user to do async and/or non-blocking I/O to an open
672 .Bl -tag -width SIOCGIFADDR
675 Returns the number of bytes that are immediately available for reading.
677 .Pq Li "struct ifreq"
678 Returns the address associated with the interface.
681 Sets or clears non-blocking I/O.
682 If arg is non-zero, then doing a
684 when no data is available will return -1 and
688 If arg is zero, non-blocking I/O is disabled.
689 Note: setting this overrides the timeout set by
693 Enables or disables async I/O.
694 When enabled (arg is non-zero), the process or process group specified by
699 Note that you must do an
701 in order for this to take affect,
702 as the system will not default this for you.
703 The signal may be changed via
708 Sets or gets the process or process group (if negative) that should
711 when packets are available.
712 The signal may be changed using
717 One of the following structures is prepended to each packet returned by
719 or via a zero-copy buffer:
722 struct bpf_ts bh_tstamp; /* time stamp */
723 uint32_t bh_caplen; /* length of captured portion */
724 uint32_t bh_datalen; /* original length of packet */
725 u_short bh_hdrlen; /* length of bpf header (this struct
726 plus alignment padding) */
730 struct timeval bh_tstamp; /* time stamp */
731 uint32_t bh_caplen; /* length of captured portion */
732 uint32_t bh_datalen; /* original length of packet */
733 u_short bh_hdrlen; /* length of bpf header (this struct
734 plus alignment padding) */
738 The fields, whose values are stored in host order, and are:
740 .Bl -tag -compact -width bh_datalen
742 The time at which the packet was processed by the packet filter.
744 The length of the captured portion of the packet.
745 This is the minimum of
746 the truncation amount specified by the filter and the length of the packet.
748 The length of the packet off the wire.
749 This value is independent of the truncation amount specified by the filter.
753 header, which may not be equal to
754 .\" XXX - not really a function call
755 .Fn sizeof "struct bpf_xhdr"
757 .Fn sizeof "struct bpf_hdr" .
762 field exists to account for
763 padding between the header and the link level protocol.
764 The purpose here is to guarantee proper alignment of the packet
765 data structures, which is required on alignment sensitive
766 architectures and improves performance on many other architectures.
767 The packet filter ensures that the
770 and the network layer
771 header will be word aligned.
774 is used when the time stamp is set to
775 .Dv BPF_T_MICROTIME ,
776 .Dv BPF_T_MICROTIME_FAST ,
777 .Dv BPF_T_MICROTIME_MONOTONIC ,
778 .Dv BPF_T_MICROTIME_MONOTONIC_FAST ,
781 for backward compatibility reasons.
787 may be deprecated in the near future.
789 must be taken when accessing the link layer protocol fields on alignment
791 (This is not a problem on an Ethernet, since
792 the type field is a short falling on an even offset,
793 and the addresses are probably accessed in a bytewise fashion).
795 Additionally, individual packets are padded so that each starts
797 This requires that an application
798 has some knowledge of how to get from packet to packet.
805 It rounds up its argument to the nearest word aligned value (where a word is
811 points to the start of a packet, this expression
812 will advance it to the next packet:
813 .Dl p = (char *)p + BPF_WORDALIGN(p->bh_hdrlen + p->bh_caplen)
815 For the alignment mechanisms to work properly, the
818 must itself be word aligned.
822 will always return an aligned buffer.
824 A filter program is an array of instructions, with all branches forwardly
825 directed, terminated by a
828 Each instruction performs some action on the pseudo-machine state,
829 which consists of an accumulator, index register, scratch memory store,
830 and implicit program counter.
832 The following structure defines the instruction format:
844 field is used in different ways by different instructions,
849 fields are used as offsets
850 by the branch instructions.
851 The opcodes are encoded in a semi-hierarchical fashion.
852 There are eight classes of instructions:
862 Various other mode and
863 operator bits are or'd into the class to give the actual instructions.
864 The classes and modes are defined in
867 Below are the semantics for each defined
870 We use the convention that A is the accumulator, X is the index register,
871 P[] packet data, and M[] scratch memory store.
872 P[i:n] gives the data at byte offset
875 interpreted as a word (n=4),
876 unsigned halfword (n=2), or unsigned byte (n=1).
877 M[i] gives the i'th word in the scratch memory store, which is only
878 addressed in word units.
879 The memory store is indexed from 0 to
886 are the corresponding fields in the
887 instruction definition.
889 refers to the length of the packet.
890 .Bl -tag -width BPF_STXx
892 These instructions copy a value into the accumulator.
893 The type of the source operand is specified by an
895 and can be a constant
897 packet data at a fixed offset
899 packet data at a variable offset
903 or a word in the scratch memory store
909 the data size must be specified as a word
915 The semantics of all the recognized
919 BPF_LD+BPF_W+BPF_ABS A <- P[k:4]
920 BPF_LD+BPF_H+BPF_ABS A <- P[k:2]
921 BPF_LD+BPF_B+BPF_ABS A <- P[k:1]
922 BPF_LD+BPF_W+BPF_IND A <- P[X+k:4]
923 BPF_LD+BPF_H+BPF_IND A <- P[X+k:2]
924 BPF_LD+BPF_B+BPF_IND A <- P[X+k:1]
925 BPF_LD+BPF_W+BPF_LEN A <- len
926 BPF_LD+BPF_IMM A <- k
927 BPF_LD+BPF_MEM A <- M[k]
930 These instructions load a value into the index register.
932 the addressing modes are more restrictive than those of the accumulator loads,
935 a hack for efficiently loading the IP header length.
937 BPF_LDX+BPF_W+BPF_IMM X <- k
938 BPF_LDX+BPF_W+BPF_MEM X <- M[k]
939 BPF_LDX+BPF_W+BPF_LEN X <- len
940 BPF_LDX+BPF_B+BPF_MSH X <- 4*(P[k:1]&0xf)
943 This instruction stores the accumulator into the scratch memory.
944 We do not need an addressing mode since there is only one possibility
950 This instruction stores the index register in the scratch memory store.
955 The alu instructions perform operations between the accumulator and
956 index register or constant, and store the result back in the accumulator.
957 For binary operations, a source mode is required
962 BPF_ALU+BPF_ADD+BPF_K A <- A + k
963 BPF_ALU+BPF_SUB+BPF_K A <- A - k
964 BPF_ALU+BPF_MUL+BPF_K A <- A * k
965 BPF_ALU+BPF_DIV+BPF_K A <- A / k
966 BPF_ALU+BPF_MOD+BPF_K A <- A % k
967 BPF_ALU+BPF_AND+BPF_K A <- A & k
968 BPF_ALU+BPF_OR+BPF_K A <- A | k
969 BPF_ALU+BPF_XOR+BPF_K A <- A ^ k
970 BPF_ALU+BPF_LSH+BPF_K A <- A << k
971 BPF_ALU+BPF_RSH+BPF_K A <- A >> k
972 BPF_ALU+BPF_ADD+BPF_X A <- A + X
973 BPF_ALU+BPF_SUB+BPF_X A <- A - X
974 BPF_ALU+BPF_MUL+BPF_X A <- A * X
975 BPF_ALU+BPF_DIV+BPF_X A <- A / X
976 BPF_ALU+BPF_MOD+BPF_X A <- A % X
977 BPF_ALU+BPF_AND+BPF_X A <- A & X
978 BPF_ALU+BPF_OR+BPF_X A <- A | X
979 BPF_ALU+BPF_XOR+BPF_X A <- A ^ X
980 BPF_ALU+BPF_LSH+BPF_X A <- A << X
981 BPF_ALU+BPF_RSH+BPF_X A <- A >> X
982 BPF_ALU+BPF_NEG A <- -A
985 The jump instructions alter flow of control.
987 compare the accumulator against a constant
989 or the index register
991 If the result is true (or non-zero),
992 the true branch is taken, otherwise the false branch is taken.
993 Jump offsets are encoded in 8 bits so the longest jump is 256 instructions.
994 However, the jump always
996 opcode uses the 32 bit
998 field as the offset, allowing arbitrarily distant destinations.
999 All conditionals use unsigned comparison conventions.
1001 BPF_JMP+BPF_JA pc += k
1002 BPF_JMP+BPF_JGT+BPF_K pc += (A > k) ? jt : jf
1003 BPF_JMP+BPF_JGE+BPF_K pc += (A >= k) ? jt : jf
1004 BPF_JMP+BPF_JEQ+BPF_K pc += (A == k) ? jt : jf
1005 BPF_JMP+BPF_JSET+BPF_K pc += (A & k) ? jt : jf
1006 BPF_JMP+BPF_JGT+BPF_X pc += (A > X) ? jt : jf
1007 BPF_JMP+BPF_JGE+BPF_X pc += (A >= X) ? jt : jf
1008 BPF_JMP+BPF_JEQ+BPF_X pc += (A == X) ? jt : jf
1009 BPF_JMP+BPF_JSET+BPF_X pc += (A & X) ? jt : jf
1012 The return instructions terminate the filter program and specify the amount
1013 of packet to accept (i.e., they return the truncation amount).
1014 A return value of zero indicates that the packet should be ignored.
1015 The return value is either a constant
1020 BPF_RET+BPF_A accept A bytes
1021 BPF_RET+BPF_K accept k bytes
1024 The miscellaneous category was created for anything that does not
1025 fit into the above classes, and for any new instructions that might need to
1027 Currently, these are the register transfer instructions
1028 that copy the index register to the accumulator or vice versa.
1030 BPF_MISC+BPF_TAX X <- A
1031 BPF_MISC+BPF_TXA A <- X
1037 interface provides the following macros to facilitate
1039 .Fn BPF_STMT opcode operand
1041 .Fn BPF_JUMP opcode operand true_offset false_offset .
1042 .Sh SYSCTL VARIABLES
1045 variables controls the behaviour of the
1048 .Bl -tag -width indent
1049 .It Va net.bpf.optimize_writers : No 0
1050 Various programs use BPF to send (but not receive) raw packets
1051 (cdpd, lldpd, dhcpd, dhcp relays, etc. are good examples of such programs).
1052 They do not need incoming packets to be send to them.
1053 Turning this option on
1054 makes new BPF users to be attached to write-only interface list until program
1055 explicitly specifies read filter via
1056 .Fn pcap_set_filter .
1057 This removes any performance degradation for high-speed interfaces.
1058 .It Va net.bpf.stats :
1059 Binary interface for retrieving general statistics.
1060 .It Va net.bpf.zerocopy_enable : No 0
1061 Permits zero-copy to be used with net BPF readers.
1063 .It Va net.bpf.maxinsns : No 512
1064 Maximum number of instructions that BPF program can contain.
1068 option to determine approximate number of instruction for any filter.
1069 .It Va net.bpf.maxbufsize : No 524288
1070 Maximum buffer size to allocate for packets buffer.
1071 .It Va net.bpf.bufsize : No 4096
1072 Default buffer size to allocate for packets buffer.
1075 The following filter is taken from the Reverse ARP Daemon.
1076 It accepts only Reverse ARP requests.
1078 struct bpf_insn insns[] = {
1079 BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
1080 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_REVARP, 0, 3),
1081 BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 20),
1082 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ARPOP_REVREQUEST, 0, 1),
1083 BPF_STMT(BPF_RET+BPF_K, sizeof(struct ether_arp) +
1084 sizeof(struct ether_header)),
1085 BPF_STMT(BPF_RET+BPF_K, 0),
1089 This filter accepts only IP packets between host 128.3.112.15 and
1092 struct bpf_insn insns[] = {
1093 BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
1094 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_IP, 0, 8),
1095 BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 26),
1096 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x8003700f, 0, 2),
1097 BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 30),
1098 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x80037023, 3, 4),
1099 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x80037023, 0, 3),
1100 BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 30),
1101 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x8003700f, 0, 1),
1102 BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
1103 BPF_STMT(BPF_RET+BPF_K, 0),
1107 Finally, this filter returns only TCP finger packets.
1108 We must parse the IP header to reach the TCP header.
1112 checks that the IP fragment offset is 0 so we are sure
1113 that we have a TCP header.
1115 struct bpf_insn insns[] = {
1116 BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
1117 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_IP, 0, 10),
1118 BPF_STMT(BPF_LD+BPF_B+BPF_ABS, 23),
1119 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, IPPROTO_TCP, 0, 8),
1120 BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 20),
1121 BPF_JUMP(BPF_JMP+BPF_JSET+BPF_K, 0x1fff, 6, 0),
1122 BPF_STMT(BPF_LDX+BPF_B+BPF_MSH, 14),
1123 BPF_STMT(BPF_LD+BPF_H+BPF_IND, 14),
1124 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 79, 2, 0),
1125 BPF_STMT(BPF_LD+BPF_H+BPF_IND, 16),
1126 BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 79, 0, 1),
1127 BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
1128 BPF_STMT(BPF_RET+BPF_K, 0),
1142 .%T "An efficient, extensible, and portable network monitor"
1145 The Enet packet filter was created in 1980 by Mike Accetta and
1146 Rick Rashid at Carnegie-Mellon University.
1148 Stanford, ported the code to
1150 and continued its development from
1152 Since then, it has evolved into the Ultrix Packet Filter at
1163 .An Steven McCanne ,
1164 of Lawrence Berkeley Laboratory, implemented BPF in
1166 Much of the design is due to
1169 Support for zero-copy buffers was added by
1170 .An Robert N. M. Watson
1171 under contract to Seccuris Inc.
1173 The read buffer must be of a fixed size (returned by the
1177 A file that does not request promiscuous mode may receive promiscuously
1178 received packets as a side effect of another file requesting this
1179 mode on the same hardware interface.
1180 This could be fixed in the kernel with additional processing overhead.
1181 However, we favor the model where
1182 all files must assume that the interface is promiscuous, and if
1183 so desired, must utilize a filter to reject foreign packets.
1190 settings have been observed to work incorrectly on some interface
1191 types, including those with hardware loopback rather than software loopback,
1192 and point-to-point interfaces.
1193 They appear to function correctly on a
1194 broad range of Ethernet-style interfaces.