nexmon – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | .\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997 |
2 | .\" The Regents of the University of California. All rights reserved. |
||
3 | .\" All rights reserved. |
||
4 | .\" |
||
5 | .\" Redistribution and use in source and binary forms, with or without |
||
6 | .\" modification, are permitted provided that: (1) source code distributions |
||
7 | .\" retain the above copyright notice and this paragraph in its entirety, (2) |
||
8 | .\" distributions including binary code include the above copyright notice and |
||
9 | .\" this paragraph in its entirety in the documentation or other materials |
||
10 | .\" provided with the distribution, and (3) all advertising materials mentioning |
||
11 | .\" features or use of this software display the following acknowledgement: |
||
12 | .\" ``This product includes software developed by the University of California, |
||
13 | .\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of |
||
14 | .\" the University nor the names of its contributors may be used to endorse |
||
15 | .\" or promote products derived from this software without specific prior |
||
16 | .\" written permission. |
||
17 | .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED |
||
18 | .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF |
||
19 | .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. |
||
20 | .\" |
||
21 | .TH PCAP-FILTER @MAN_MISC_INFO@ "17 May 2013" |
||
22 | .SH NAME |
||
23 | pcap-filter \- packet filter syntax |
||
24 | .br |
||
25 | .ad |
||
26 | .SH DESCRIPTION |
||
27 | .LP |
||
28 | .B pcap_compile() |
||
29 | is used to compile a string into a filter program. |
||
30 | The resulting filter program can then be applied to |
||
31 | some stream of packets to determine which packets will be supplied to |
||
32 | .BR pcap_loop() , |
||
33 | .BR pcap_dispatch() , |
||
34 | .BR pcap_next() , |
||
35 | or |
||
36 | .BR pcap_next_ex() . |
||
37 | .LP |
||
38 | The \fIfilter expression\fP consists of one or more |
||
39 | .IR primitives . |
||
40 | Primitives usually consist of an |
||
41 | .I id |
||
42 | (name or number) preceded by one or more qualifiers. |
||
43 | There are three |
||
44 | different kinds of qualifier: |
||
45 | .IP \fItype\fP |
||
46 | .I type |
||
47 | qualifiers say what kind of thing the id name or number refers to. |
||
48 | Possible types are |
||
49 | .BR host , |
||
50 | .B net , |
||
51 | .B port |
||
52 | and |
||
53 | .BR portrange . |
||
54 | E.g., `host foo', `net 128.3', `port 20', `portrange 6000-6008'. |
||
55 | If there is no type |
||
56 | qualifier, |
||
57 | .B host |
||
58 | is assumed. |
||
59 | .IP \fIdir\fP |
||
60 | .I dir |
||
61 | qualifiers specify a particular transfer direction to and/or from |
||
62 | .IR id . |
||
63 | Possible directions are |
||
64 | .BR src , |
||
65 | .BR dst , |
||
66 | .BR "src or dst" , |
||
67 | .BR "src and dst" , |
||
68 | .BR ra , |
||
69 | .BR ta , |
||
70 | .BR addr1 , |
||
71 | .BR addr2 , |
||
72 | .BR addr3 , |
||
73 | and |
||
74 | .BR addr4 . |
||
75 | E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. |
||
76 | If |
||
77 | there is no dir qualifier, |
||
78 | .B "src or dst" |
||
79 | is assumed. |
||
80 | The |
||
81 | .BR ra , |
||
82 | .BR ta , |
||
83 | .BR addr1 , |
||
84 | .BR addr2 , |
||
85 | .BR addr3 , |
||
86 | and |
||
87 | .B addr4 |
||
88 | qualifiers are only valid for IEEE 802.11 Wireless LAN link layers. |
||
89 | For some link layers, such as SLIP and the ``cooked'' Linux capture mode |
||
90 | used for the ``any'' device and for some other device types, the |
||
91 | .B inbound |
||
92 | and |
||
93 | .B outbound |
||
94 | qualifiers can be used to specify a desired direction. |
||
95 | .IP \fIproto\fP |
||
96 | .I proto |
||
97 | qualifiers restrict the match to a particular protocol. |
||
98 | Possible |
||
99 | protos are: |
||
100 | .BR ether , |
||
101 | .BR fddi , |
||
102 | .BR tr , |
||
103 | .BR wlan , |
||
104 | .BR ip , |
||
105 | .BR ip6 , |
||
106 | .BR arp , |
||
107 | .BR rarp , |
||
108 | .BR decnet , |
||
109 | .B tcp |
||
110 | and |
||
111 | .BR udp . |
||
112 | E.g., `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange |
||
113 | 7000-7009', `wlan addr2 0:2:3:4:5:6'. |
||
114 | If there is |
||
115 | no proto qualifier, all protocols consistent with the type are |
||
116 | assumed. |
||
117 | E.g., `src foo' means `(ip or arp or rarp) src foo' |
||
118 | (except the latter is not legal syntax), `net bar' means `(ip or |
||
119 | arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'. |
||
120 | .LP |
||
121 | [`fddi' is actually an alias for `ether'; the parser treats them |
||
122 | identically as meaning ``the data link level used on the specified |
||
123 | network interface.'' FDDI headers contain Ethernet-like source |
||
124 | and destination addresses, and often contain Ethernet-like packet |
||
125 | types, so you can filter on these FDDI fields just as with the |
||
126 | analogous Ethernet fields. |
||
127 | FDDI headers also contain other fields, |
||
128 | but you cannot name them explicitly in a filter expression. |
||
129 | .LP |
||
130 | Similarly, `tr' and `wlan' are aliases for `ether'; the previous |
||
131 | paragraph's statements about FDDI headers also apply to Token Ring |
||
132 | and 802.11 wireless LAN headers. For 802.11 headers, the destination |
||
133 | address is the DA field and the source address is the SA field; the |
||
134 | BSSID, RA, and TA fields aren't tested.] |
||
135 | .LP |
||
136 | In addition to the above, there are some special `primitive' keywords |
||
137 | that don't follow the pattern: |
||
138 | .BR gateway , |
||
139 | .BR broadcast , |
||
140 | .BR less , |
||
141 | .B greater |
||
142 | and arithmetic expressions. |
||
143 | All of these are described below. |
||
144 | .LP |
||
145 | More complex filter expressions are built up by using the words |
||
146 | .BR and , |
||
147 | .B or |
||
148 | and |
||
149 | .B not |
||
150 | to combine primitives. |
||
151 | E.g., `host foo and not port ftp and not port ftp-data'. |
||
152 | To save typing, identical qualifier lists can be omitted. |
||
153 | E.g., |
||
154 | `tcp dst port ftp or ftp-data or domain' is exactly the same as |
||
155 | `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'. |
||
156 | .LP |
||
157 | Allowable primitives are: |
||
158 | .IP "\fBdst host \fIhost\fR" |
||
159 | True if the IPv4/v6 destination field of the packet is \fIhost\fP, |
||
160 | which may be either an address or a name. |
||
161 | .IP "\fBsrc host \fIhost\fR" |
||
162 | True if the IPv4/v6 source field of the packet is \fIhost\fP. |
||
163 | .IP "\fBhost \fIhost\fP" |
||
164 | True if either the IPv4/v6 source or destination of the packet is \fIhost\fP. |
||
165 | .IP |
||
166 | Any of the above host expressions can be prepended with the keywords, |
||
167 | \fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in: |
||
168 | .in +.5i |
||
169 | .nf |
||
170 | \fBip host \fIhost\fR |
||
171 | .fi |
||
172 | .in -.5i |
||
173 | which is equivalent to: |
||
174 | .in +.5i |
||
175 | .nf |
||
176 | \fBether proto \fI\\ip\fB and host \fIhost\fR |
||
177 | .fi |
||
178 | .in -.5i |
||
179 | If \fIhost\fR is a name with multiple IP addresses, each address will |
||
180 | be checked for a match. |
||
181 | .IP "\fBether dst \fIehost\fP" |
||
182 | True if the Ethernet destination address is \fIehost\fP. |
||
183 | \fIEhost\fP |
||
184 | may be either a name from /etc/ethers or a number (see |
||
185 | .IR ethers (3N) |
||
186 | for numeric format). |
||
187 | .IP "\fBether src \fIehost\fP" |
||
188 | True if the Ethernet source address is \fIehost\fP. |
||
189 | .IP "\fBether host \fIehost\fP" |
||
190 | True if either the Ethernet source or destination address is \fIehost\fP. |
||
191 | .IP "\fBgateway\fP \fIhost\fP" |
||
192 | True if the packet used \fIhost\fP as a gateway. |
||
193 | I.e., the Ethernet |
||
194 | source or destination address was \fIhost\fP but neither the IP source |
||
195 | nor the IP destination was \fIhost\fP. |
||
196 | \fIHost\fP must be a name and |
||
197 | must be found both by the machine's host-name-to-IP-address resolution |
||
198 | mechanisms (host name file, DNS, NIS, etc.) and by the machine's |
||
199 | host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.). |
||
200 | (An equivalent expression is |
||
201 | .in +.5i |
||
202 | .nf |
||
203 | \fBether host \fIehost \fBand not host \fIhost\fR |
||
204 | .fi |
||
205 | .in -.5i |
||
206 | which can be used with either names or numbers for \fIhost / ehost\fP.) |
||
207 | This syntax does not work in IPv6-enabled configuration at this moment. |
||
208 | .IP "\fBdst net \fInet\fR" |
||
209 | True if the IPv4/v6 destination address of the packet has a network |
||
210 | number of \fInet\fP. |
||
211 | \fINet\fP may be either a name from the networks database |
||
212 | (/etc/networks, etc.) or a network number. |
||
213 | An IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0), |
||
214 | dotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or single |
||
215 | number (e.g., 10); the netmask is 255.255.255.255 for a dotted quad |
||
216 | (which means that it's really a host match), 255.255.255.0 for a dotted |
||
217 | triple, 255.255.0.0 for a dotted pair, or 255.0.0.0 for a single number. |
||
218 | An IPv6 network number must be written out fully; the netmask is |
||
219 | ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 "network" matches are really always |
||
220 | host matches, and a network match requires a netmask length. |
||
221 | .IP "\fBsrc net \fInet\fR" |
||
222 | True if the IPv4/v6 source address of the packet has a network |
||
223 | number of \fInet\fP. |
||
224 | .IP "\fBnet \fInet\fR" |
||
225 | True if either the IPv4/v6 source or destination address of the packet has a network |
||
226 | number of \fInet\fP. |
||
227 | .IP "\fBnet \fInet\fR \fBmask \fInetmask\fR" |
||
228 | True if the IPv4 address matches \fInet\fR with the specific \fInetmask\fR. |
||
229 | May be qualified with \fBsrc\fR or \fBdst\fR. |
||
230 | Note that this syntax is not valid for IPv6 \fInet\fR. |
||
231 | .IP "\fBnet \fInet\fR/\fIlen\fR" |
||
232 | True if the IPv4/v6 address matches \fInet\fR with a netmask \fIlen\fR |
||
233 | bits wide. |
||
234 | May be qualified with \fBsrc\fR or \fBdst\fR. |
||
235 | .IP "\fBdst port \fIport\fR" |
||
236 | True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a |
||
237 | destination port value of \fIport\fP. |
||
238 | The \fIport\fP can be a number or a name used in /etc/services (see |
||
239 | .IR tcp (4P) |
||
240 | and |
||
241 | .IR udp (4P)). |
||
242 | If a name is used, both the port |
||
243 | number and protocol are checked. |
||
244 | If a number or ambiguous name is used, |
||
245 | only the port number is checked (e.g., \fBdst port 513\fR will print both |
||
246 | tcp/login traffic and udp/who traffic, and \fBport domain\fR will print |
||
247 | both tcp/domain and udp/domain traffic). |
||
248 | .IP "\fBsrc port \fIport\fR" |
||
249 | True if the packet has a source port value of \fIport\fP. |
||
250 | .IP "\fBport \fIport\fR" |
||
251 | True if either the source or destination port of the packet is \fIport\fP. |
||
252 | .IP "\fBdst portrange \fIport1\fB-\fIport2\fR" |
||
253 | True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a |
||
254 | destination port value between \fIport1\fP and \fIport2\fP. |
||
255 | .I port1 |
||
256 | and |
||
257 | .I port2 |
||
258 | are interpreted in the same fashion as the |
||
259 | .I port |
||
260 | parameter for |
||
261 | .BR port . |
||
262 | .IP "\fBsrc portrange \fIport1\fB-\fIport2\fR" |
||
263 | True if the packet has a source port value between \fIport1\fP and |
||
264 | \fIport2\fP. |
||
265 | .IP "\fBportrange \fIport1\fB-\fIport2\fR" |
||
266 | True if either the source or destination port of the packet is between |
||
267 | \fIport1\fP and \fIport2\fP. |
||
268 | .IP |
||
269 | Any of the above port or port range expressions can be prepended with |
||
270 | the keywords, \fBtcp\fP or \fBudp\fP, as in: |
||
271 | .in +.5i |
||
272 | .nf |
||
273 | \fBtcp src port \fIport\fR |
||
274 | .fi |
||
275 | .in -.5i |
||
276 | which matches only tcp packets whose source port is \fIport\fP. |
||
277 | .IP "\fBless \fIlength\fR" |
||
278 | True if the packet has a length less than or equal to \fIlength\fP. |
||
279 | This is equivalent to: |
||
280 | .in +.5i |
||
281 | .nf |
||
282 | \fBlen <= \fIlength\fP. |
||
283 | .fi |
||
284 | .in -.5i |
||
285 | .IP "\fBgreater \fIlength\fR" |
||
286 | True if the packet has a length greater than or equal to \fIlength\fP. |
||
287 | This is equivalent to: |
||
288 | .in +.5i |
||
289 | .nf |
||
290 | \fBlen >= \fIlength\fP. |
||
291 | .fi |
||
292 | .in -.5i |
||
293 | .IP "\fBip proto \fIprotocol\fR" |
||
294 | True if the packet is an IPv4 packet (see |
||
295 | .IR ip (4P)) |
||
296 | of protocol type \fIprotocol\fP. |
||
297 | \fIProtocol\fP can be a number or one of the names |
||
298 | \fBicmp\fP, \fBicmp6\fP, \fBigmp\fP, \fBigrp\fP, \fBpim\fP, \fBah\fP, |
||
299 | \fBesp\fP, \fBvrrp\fP, \fBudp\fP, or \fBtcp\fP. |
||
300 | Note that the identifiers \fBtcp\fP, \fBudp\fP, and \fBicmp\fP are also |
||
301 | keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell. |
||
302 | Note that this primitive does not chase the protocol header chain. |
||
303 | .IP "\fBip6 proto \fIprotocol\fR" |
||
304 | True if the packet is an IPv6 packet of protocol type \fIprotocol\fP. |
||
305 | Note that this primitive does not chase the protocol header chain. |
||
306 | .IP "\fBproto \fIprotocol\fR" |
||
307 | True if the packet is an IPv4 or IPv6 packet of protocol type |
||
308 | \fIprotocol\fP. Note that this primitive does not chase the protocol |
||
309 | header chain. |
||
310 | .IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR" |
||
311 | Abbreviations for: |
||
312 | .in +.5i |
||
313 | .nf |
||
314 | \fBproto \fIp\fR\fB |
||
315 | .fi |
||
316 | .in -.5i |
||
317 | where \fIp\fR is one of the above protocols. |
||
318 | .IP "\fBip6 protochain \fIprotocol\fR" |
||
319 | True if the packet is IPv6 packet, |
||
320 | and contains protocol header with type \fIprotocol\fR |
||
321 | in its protocol header chain. |
||
322 | For example, |
||
323 | .in +.5i |
||
324 | .nf |
||
325 | \fBip6 protochain 6\fR |
||
326 | .fi |
||
327 | .in -.5i |
||
328 | matches any IPv6 packet with TCP protocol header in the protocol header chain. |
||
329 | The packet may contain, for example, |
||
330 | authentication header, routing header, or hop-by-hop option header, |
||
331 | between IPv6 header and TCP header. |
||
332 | The BPF code emitted by this primitive is complex and |
||
333 | cannot be optimized by the BPF optimizer code, and is not supported by |
||
334 | filter engines in the kernel, so this can be somewhat slow, and may |
||
335 | cause more packets to be dropped. |
||
336 | .IP "\fBip protochain \fIprotocol\fR" |
||
337 | Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4. |
||
338 | .IP "\fBprotochain \fIprotocol\fR" |
||
339 | True if the packet is an IPv4 or IPv6 packet of protocol type |
||
340 | \fIprotocol\fP. Note that this primitive chases the protocol |
||
341 | header chain. |
||
342 | .IP "\fBether broadcast\fR" |
||
343 | True if the packet is an Ethernet broadcast packet. |
||
344 | The \fIether\fP |
||
345 | keyword is optional. |
||
346 | .IP "\fBip broadcast\fR" |
||
347 | True if the packet is an IPv4 broadcast packet. |
||
348 | It checks for both the all-zeroes and all-ones broadcast conventions, |
||
349 | and looks up the subnet mask on the interface on which the capture is |
||
350 | being done. |
||
351 | .IP |
||
352 | If the subnet mask of the interface on which the capture is being done |
||
353 | is not available, either because the interface on which capture is being |
||
354 | done has no netmask or because the capture is being done on the Linux |
||
355 | "any" interface, which can capture on more than one interface, this |
||
356 | check will not work correctly. |
||
357 | .IP "\fBether multicast\fR" |
||
358 | True if the packet is an Ethernet multicast packet. |
||
359 | The \fBether\fP |
||
360 | keyword is optional. |
||
361 | This is shorthand for `\fBether[0] & 1 != 0\fP'. |
||
362 | .IP "\fBip multicast\fR" |
||
363 | True if the packet is an IPv4 multicast packet. |
||
364 | .IP "\fBip6 multicast\fR" |
||
365 | True if the packet is an IPv6 multicast packet. |
||
366 | .IP "\fBether proto \fIprotocol\fR" |
||
367 | True if the packet is of ether type \fIprotocol\fR. |
||
368 | \fIProtocol\fP can be a number or one of the names |
||
369 | \fBip\fP, \fBip6\fP, \fBarp\fP, \fBrarp\fP, \fBatalk\fP, \fBaarp\fP, |
||
370 | \fBdecnet\fP, \fBsca\fP, \fBlat\fP, \fBmopdl\fP, \fBmoprc\fP, |
||
371 | \fBiso\fP, \fBstp\fP, \fBipx\fP, or \fBnetbeui\fP. |
||
372 | Note these identifiers are also keywords |
||
373 | and must be escaped via backslash (\\). |
||
374 | .IP |
||
375 | [In the case of FDDI (e.g., `\fBfddi protocol arp\fR'), Token Ring |
||
376 | (e.g., `\fBtr protocol arp\fR'), and IEEE 802.11 wireless LANS (e.g., |
||
377 | `\fBwlan protocol arp\fR'), for most of those protocols, the |
||
378 | protocol identification comes from the 802.2 Logical Link Control (LLC) |
||
379 | header, which is usually layered on top of the FDDI, Token Ring, or |
||
380 | 802.11 header. |
||
381 | .IP |
||
382 | When filtering for most protocol identifiers on FDDI, Token Ring, or |
||
383 | 802.11, the filter checks only the protocol ID field of an LLC header |
||
384 | in so-called SNAP format with an Organizational Unit Identifier (OUI) of |
||
385 | 0x000000, for encapsulated Ethernet; it doesn't check whether the packet |
||
386 | is in SNAP format with an OUI of 0x000000. |
||
387 | The exceptions are: |
||
388 | .RS |
||
389 | .TP |
||
390 | \fBiso\fP |
||
391 | the filter checks the DSAP (Destination Service Access Point) and |
||
392 | SSAP (Source Service Access Point) fields of the LLC header; |
||
393 | .TP |
||
394 | \fBstp\fP and \fBnetbeui\fP |
||
395 | the filter checks the DSAP of the LLC header; |
||
396 | .TP |
||
397 | \fBatalk\fP |
||
398 | the filter checks for a SNAP-format packet with an OUI of 0x080007 |
||
399 | and the AppleTalk etype. |
||
400 | .RE |
||
401 | .IP |
||
402 | In the case of Ethernet, the filter checks the Ethernet type field |
||
403 | for most of those protocols. The exceptions are: |
||
404 | .RS |
||
405 | .TP |
||
406 | \fBiso\fP, \fBstp\fP, and \fBnetbeui\fP |
||
407 | the filter checks for an 802.3 frame and then checks the LLC header as |
||
408 | it does for FDDI, Token Ring, and 802.11; |
||
409 | .TP |
||
410 | \fBatalk\fP |
||
411 | the filter checks both for the AppleTalk etype in an Ethernet frame and |
||
412 | for a SNAP-format packet as it does for FDDI, Token Ring, and 802.11; |
||
413 | .TP |
||
414 | \fBaarp\fP |
||
415 | the filter checks for the AppleTalk ARP etype in either an Ethernet |
||
416 | frame or an 802.2 SNAP frame with an OUI of 0x000000; |
||
417 | .TP |
||
418 | \fBipx\fP |
||
419 | the filter checks for the IPX etype in an Ethernet frame, the IPX |
||
420 | DSAP in the LLC header, the 802.3-with-no-LLC-header encapsulation of |
||
421 | IPX, and the IPX etype in a SNAP frame. |
||
422 | .RE |
||
423 | .IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fBnetbeui\fP" |
||
424 | Abbreviations for: |
||
425 | .in +.5i |
||
426 | .nf |
||
427 | \fBether proto \fIp\fR |
||
428 | .fi |
||
429 | .in -.5i |
||
430 | where \fIp\fR is one of the above protocols. |
||
431 | .IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR" |
||
432 | Abbreviations for: |
||
433 | .in +.5i |
||
434 | .nf |
||
435 | \fBether proto \fIp\fR |
||
436 | .fi |
||
437 | .in -.5i |
||
438 | where \fIp\fR is one of the above protocols. |
||
439 | Note that not all applications using |
||
440 | .BR pcap (3PCAP) |
||
441 | currently know how to parse these protocols. |
||
442 | .IP "\fBdecnet src \fIhost\fR" |
||
443 | True if the DECNET source address is |
||
444 | .IR host , |
||
445 | which may be an address of the form ``10.123'', or a DECNET host |
||
446 | name. |
||
447 | [DECNET host name support is only available on ULTRIX systems |
||
448 | that are configured to run DECNET.] |
||
449 | .IP "\fBdecnet dst \fIhost\fR" |
||
450 | True if the DECNET destination address is |
||
451 | .IR host . |
||
452 | .IP "\fBdecnet host \fIhost\fR" |
||
453 | True if either the DECNET source or destination address is |
||
454 | .IR host . |
||
455 | .IP \fBllc\fP |
||
456 | True if the packet has an 802.2 LLC header. This includes: |
||
457 | .IP |
||
458 | Ethernet packets with a length field rather than a type field that |
||
459 | aren't raw NetWare-over-802.3 packets; |
||
460 | .IP |
||
461 | IEEE 802.11 data packets; |
||
462 | .IP |
||
463 | Token Ring packets (no check is done for LLC frames); |
||
464 | .IP |
||
465 | FDDI packets (no check is done for LLC frames); |
||
466 | .IP |
||
467 | LLC-encapsulated ATM packets, for SunATM on Solaris. |
||
468 | .IP |
||
469 | |||
470 | .IP "\fBllc\fP \Fitype\fR" |
||
471 | True if the packet has an 802.2 LLC header and has the specified |
||
472 | .IR type . |
||
473 | .I type |
||
474 | can be one of: |
||
475 | .RS |
||
476 | .TP |
||
477 | \fBi\fR |
||
478 | Information (I) PDUs |
||
479 | .TP |
||
480 | \fBs\fR |
||
481 | Supervisory (S) PDUs |
||
482 | .TP |
||
483 | \fBu\fR |
||
484 | Unnumbered (U) PDUs |
||
485 | .TP |
||
486 | \fBrr\fR |
||
487 | Receiver Ready (RR) S PDUs |
||
488 | .TP |
||
489 | \fBrnr\fR |
||
490 | Receiver Not Ready (RNR) S PDUs |
||
491 | .TP |
||
492 | \fBrej\fR |
||
493 | Reject (REJ) S PDUs |
||
494 | .TP |
||
495 | \fBui\fR |
||
496 | Unnumbered Information (UI) U PDUs |
||
497 | .TP |
||
498 | \fBua\fR |
||
499 | Unnumbered Acknowledgment (UA) U PDUs |
||
500 | .TP |
||
501 | \fBdisc\fR |
||
502 | Disconnect (DISC) U PDUs |
||
503 | .TP |
||
504 | \fBsabme\fR |
||
505 | Set Asynchronous Balanced Mode Extended (SABME) U PDUs |
||
506 | .TP |
||
507 | \fBtest\fR |
||
508 | Test (TEST) U PDUs |
||
509 | .TP |
||
510 | \fBxid\fR |
||
511 | Exchange Identification (XID) U PDUs |
||
512 | .TP |
||
513 | \fBfrmr\fR |
||
514 | Frame Reject (FRMR) U PDUs |
||
515 | .RE |
||
516 | .IP "\fBifname \fIinterface\fR" |
||
517 | True if the packet was logged as coming from the specified interface (applies |
||
518 | only to packets logged by OpenBSD's or FreeBSD's |
||
519 | .BR pf (4)). |
||
520 | .IP "\fBon \fIinterface\fR" |
||
521 | Synonymous with the |
||
522 | .B ifname |
||
523 | modifier. |
||
524 | .IP "\fBrnr \fInum\fR" |
||
525 | True if the packet was logged as matching the specified PF rule number |
||
526 | (applies only to packets logged by OpenBSD's or FreeBSD's |
||
527 | .BR pf (4)). |
||
528 | .IP "\fBrulenum \fInum\fR" |
||
529 | Synonymous with the |
||
530 | .B rnr |
||
531 | modifier. |
||
532 | .IP "\fBreason \fIcode\fR" |
||
533 | True if the packet was logged with the specified PF reason code. The known |
||
534 | codes are: |
||
535 | .BR match , |
||
536 | .BR bad-offset , |
||
537 | .BR fragment , |
||
538 | .BR short , |
||
539 | .BR normalize , |
||
540 | and |
||
541 | .B memory |
||
542 | (applies only to packets logged by OpenBSD's or FreeBSD's |
||
543 | .BR pf (4)). |
||
544 | .IP "\fBrset \fIname\fR" |
||
545 | True if the packet was logged as matching the specified PF ruleset |
||
546 | name of an anchored ruleset (applies only to packets logged by OpenBSD's |
||
547 | or FreeBSD's |
||
548 | .BR pf (4)). |
||
549 | .IP "\fBruleset \fIname\fR" |
||
550 | Synonymous with the |
||
551 | .B rset |
||
552 | modifier. |
||
553 | .IP "\fBsrnr \fInum\fR" |
||
554 | True if the packet was logged as matching the specified PF rule number |
||
555 | of an anchored ruleset (applies only to packets logged by OpenBSD's or |
||
556 | FreeBSD's |
||
557 | .BR pf (4)). |
||
558 | .IP "\fBsubrulenum \fInum\fR" |
||
559 | Synonymous with the |
||
560 | .B srnr |
||
561 | modifier. |
||
562 | .IP "\fBaction \fIact\fR" |
||
563 | True if PF took the specified action when the packet was logged. Known actions |
||
564 | are: |
||
565 | .B pass |
||
566 | and |
||
567 | .B block |
||
568 | and, with later versions of |
||
569 | .BR pf (4)), |
||
570 | .BR nat , |
||
571 | .BR rdr , |
||
572 | .B binat |
||
573 | and |
||
574 | .B scrub |
||
575 | (applies only to packets logged by OpenBSD's or FreeBSD's |
||
576 | .BR pf (4)). |
||
577 | .IP "\fBwlan ra \fIehost\fR" |
||
578 | True if the IEEE 802.11 RA is |
||
579 | .IR ehost . |
||
580 | The RA field is used in all frames except for management frames. |
||
581 | .IP "\fBwlan ta \fIehost\fR" |
||
582 | True if the IEEE 802.11 TA is |
||
583 | .IR ehost . |
||
584 | The TA field is used in all frames except for management frames and |
||
585 | CTS (Clear To Send) and ACK (Acknowledgment) control frames. |
||
586 | .IP "\fBwlan addr1 \fIehost\fR" |
||
587 | True if the first IEEE 802.11 address is |
||
588 | .IR ehost . |
||
589 | .IP "\fBwlan addr2 \fIehost\fR" |
||
590 | True if the second IEEE 802.11 address, if present, is |
||
591 | .IR ehost . |
||
592 | The second address field is used in all frames except for CTS (Clear To |
||
593 | Send) and ACK (Acknowledgment) control frames. |
||
594 | .IP "\fBwlan addr3 \fIehost\fR" |
||
595 | True if the third IEEE 802.11 address, if present, is |
||
596 | .IR ehost . |
||
597 | The third address field is used in management and data frames, but not |
||
598 | in control frames. |
||
599 | .IP "\fBwlan addr4 \fIehost\fR" |
||
600 | True if the fourth IEEE 802.11 address, if present, is |
||
601 | .IR ehost . |
||
602 | The fourth address field is only used for |
||
603 | WDS (Wireless Distribution System) frames. |
||
604 | .IP "\fBtype \fIwlan_type\fR" |
||
605 | True if the IEEE 802.11 frame type matches the specified \fIwlan_type\fR. |
||
606 | Valid \fIwlan_type\fRs are: |
||
607 | \fBmgt\fP, |
||
608 | \fBctl\fP |
||
609 | and \fBdata\fP. |
||
610 | .IP "\fBtype \fIwlan_type \fBsubtype \fIwlan_subtype\fR" |
||
611 | True if the IEEE 802.11 frame type matches the specified \fIwlan_type\fR |
||
612 | and frame subtype matches the specified \fIwlan_subtype\fR. |
||
613 | .IP |
||
614 | If the specified \fIwlan_type\fR is \fBmgt\fP, |
||
615 | then valid \fIwlan_subtype\fRs are: |
||
616 | \fBassoc-req\fP, |
||
617 | \fBassoc-resp\fP, |
||
618 | \fBreassoc-req\fP, |
||
619 | \fBreassoc-resp\fP, |
||
620 | \fBprobe-req\fP, |
||
621 | \fBprobe-resp\fP, |
||
622 | \fBbeacon\fP, |
||
623 | \fBatim\fP, |
||
624 | \fBdisassoc\fP, |
||
625 | \fBauth\fP and |
||
626 | \fBdeauth\fP. |
||
627 | .IP |
||
628 | If the specified \fIwlan_type\fR is \fBctl\fP, |
||
629 | then valid \fIwlan_subtype\fRs are: |
||
630 | \fBps-poll\fP, |
||
631 | \fBrts\fP, |
||
632 | \fBcts\fP, |
||
633 | \fBack\fP, |
||
634 | \fBcf-end\fP and |
||
635 | \fBcf-end-ack\fP. |
||
636 | .IP |
||
637 | If the specified \fIwlan_type\fR is \fBdata\fP, |
||
638 | then valid \fIwlan_subtype\fRs are: |
||
639 | \fBdata\fP, |
||
640 | \fBdata-cf-ack\fP, |
||
641 | \fBdata-cf-poll\fP, |
||
642 | \fBdata-cf-ack-poll\fP, |
||
643 | \fBnull\fP, |
||
644 | \fBcf-ack\fP, |
||
645 | \fBcf-poll\fP, |
||
646 | \fBcf-ack-poll\fP, |
||
647 | \fBqos-data\fP, |
||
648 | \fBqos-data-cf-ack\fP, |
||
649 | \fBqos-data-cf-poll\fP, |
||
650 | \fBqos-data-cf-ack-poll\fP, |
||
651 | \fBqos\fP, |
||
652 | \fBqos-cf-poll\fP and |
||
653 | \fBqos-cf-ack-poll\fP. |
||
654 | .IP "\fBsubtype \fIwlan_subtype\fR" |
||
655 | True if the IEEE 802.11 frame subtype matches the specified \fIwlan_subtype\fR |
||
656 | and frame has the type to which the specified \fIwlan_subtype\fR belongs. |
||
657 | .IP "\fBdir \fIdir\fR" |
||
658 | True if the IEEE 802.11 frame direction matches the specified |
||
659 | .IR dir . |
||
660 | Valid directions are: |
||
661 | .BR nods , |
||
662 | .BR tods , |
||
663 | .BR fromds , |
||
664 | .BR dstods , |
||
665 | or a numeric value. |
||
666 | .IP "\fBvlan \fI[vlan_id]\fR" |
||
667 | True if the packet is an IEEE 802.1Q VLAN packet. |
||
668 | If \fI[vlan_id]\fR is specified, only true if the packet has the specified |
||
669 | \fIvlan_id\fR. |
||
670 | Note that the first \fBvlan\fR keyword encountered in \fIexpression\fR |
||
671 | changes the decoding offsets for the remainder of \fIexpression\fR on |
||
672 | the assumption that the packet is a VLAN packet. The \fBvlan |
||
673 | \fI[vlan_id]\fR expression may be used more than once, to filter on VLAN |
||
674 | hierarchies. Each use of that expression increments the filter offsets |
||
675 | by 4. |
||
676 | .IP |
||
677 | For example: |
||
678 | .in +.5i |
||
679 | .nf |
||
680 | \fBvlan 100 && vlan 200\fR |
||
681 | .fi |
||
682 | .in -.5i |
||
683 | filters on VLAN 200 encapsulated within VLAN 100, and |
||
684 | .in +.5i |
||
685 | .nf |
||
686 | \fBvlan && vlan 300 && ip\fR |
||
687 | .fi |
||
688 | .in -.5i |
||
689 | filters IPv4 protocols encapsulated in VLAN 300 encapsulated within any |
||
690 | higher order VLAN. |
||
691 | .IP "\fBmpls \fI[label_num]\fR" |
||
692 | True if the packet is an MPLS packet. |
||
693 | If \fI[label_num]\fR is specified, only true is the packet has the specified |
||
694 | \fIlabel_num\fR. |
||
695 | Note that the first \fBmpls\fR keyword encountered in \fIexpression\fR |
||
696 | changes the decoding offsets for the remainder of \fIexpression\fR on |
||
697 | the assumption that the packet is a MPLS-encapsulated IP packet. The |
||
698 | \fBmpls \fI[label_num]\fR expression may be used more than once, to |
||
699 | filter on MPLS hierarchies. Each use of that expression increments the |
||
700 | filter offsets by 4. |
||
701 | .IP |
||
702 | For example: |
||
703 | .in +.5i |
||
704 | .nf |
||
705 | \fBmpls 100000 && mpls 1024\fR |
||
706 | .fi |
||
707 | .in -.5i |
||
708 | filters packets with an outer label of 100000 and an inner label of |
||
709 | 1024, and |
||
710 | .in +.5i |
||
711 | .nf |
||
712 | \fBmpls && mpls 1024 && host 192.9.200.1\fR |
||
713 | .fi |
||
714 | .in -.5i |
||
715 | filters packets to or from 192.9.200.1 with an inner label of 1024 and |
||
716 | any outer label. |
||
717 | .IP \fBpppoed\fP |
||
718 | True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet |
||
719 | type 0x8863). |
||
720 | .IP "\fBpppoes \fI[session_id]\fR" |
||
721 | True if the packet is a PPP-over-Ethernet Session packet (Ethernet |
||
722 | type 0x8864). |
||
723 | If \fI[session_id]\fR is specified, only true if the packet has the specified |
||
724 | \fIsession_id\fR. |
||
725 | Note that the first \fBpppoes\fR keyword encountered in \fIexpression\fR |
||
726 | changes the decoding offsets for the remainder of \fIexpression\fR on |
||
727 | the assumption that the packet is a PPPoE session packet. |
||
728 | .IP |
||
729 | For example: |
||
730 | .in +.5i |
||
731 | .nf |
||
732 | \fBpppoes 0x27 && ip\fR |
||
733 | .fi |
||
734 | .in -.5i |
||
735 | filters IPv4 protocols encapsulated in PPPoE session id 0x27. |
||
736 | .IP "\fBgeneve \fI[vni]\fR" |
||
737 | True if the packet is a Geneve packet (UDP port 6081). If \fI[vni]\fR |
||
738 | is specified, only true if the packet has the specified \fIvni\fR. |
||
739 | Note that when the \fBgeneve\fR keyword is encountered in |
||
740 | \fIexpression\fR, it changes the decoding offsets for the remainder of |
||
741 | \fIexpression\fR on the assumption that the packet is a Geneve packet. |
||
742 | .IP |
||
743 | For example: |
||
744 | .in +.5i |
||
745 | .nf |
||
746 | \fBgeneve 0xb && ip\fR |
||
747 | .fi |
||
748 | .in -.5i |
||
749 | filters IPv4 protocols encapsulated in Geneve with VNI 0xb. This will |
||
750 | match both IP directly encapsulated in Geneve as well as IP contained |
||
751 | inside an Ethernet frame. |
||
752 | .IP "\fBiso proto \fIprotocol\fR" |
||
753 | True if the packet is an OSI packet of protocol type \fIprotocol\fP. |
||
754 | \fIProtocol\fP can be a number or one of the names |
||
755 | \fBclnp\fP, \fBesis\fP, or \fBisis\fP. |
||
756 | .IP "\fBclnp\fR, \fBesis\fR, \fBisis\fR" |
||
757 | Abbreviations for: |
||
758 | .in +.5i |
||
759 | .nf |
||
760 | \fBiso proto \fIp\fR |
||
761 | .fi |
||
762 | .in -.5i |
||
763 | where \fIp\fR is one of the above protocols. |
||
764 | .IP "\fBl1\fR, \fBl2\fR, \fBiih\fR, \fBlsp\fR, \fBsnp\fR, \fBcsnp\fR, \fBpsnp\fR" |
||
765 | Abbreviations for IS-IS PDU types. |
||
766 | .IP "\fBvpi\fP \fIn\fR" |
||
767 | True if the packet is an ATM packet, for SunATM on Solaris, with a |
||
768 | virtual path identifier of |
||
769 | .IR n . |
||
770 | .IP "\fBvci\fP \fIn\fR" |
||
771 | True if the packet is an ATM packet, for SunATM on Solaris, with a |
||
772 | virtual channel identifier of |
||
773 | .IR n . |
||
774 | .IP \fBlane\fP |
||
775 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
776 | an ATM LANE packet. |
||
777 | Note that the first \fBlane\fR keyword encountered in \fIexpression\fR |
||
778 | changes the tests done in the remainder of \fIexpression\fR |
||
779 | on the assumption that the packet is either a LANE emulated Ethernet |
||
780 | packet or a LANE LE Control packet. If \fBlane\fR isn't specified, the |
||
781 | tests are done under the assumption that the packet is an |
||
782 | LLC-encapsulated packet. |
||
783 | .IP \fBoamf4s\fP |
||
784 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
785 | a segment OAM F4 flow cell (VPI=0 & VCI=3). |
||
786 | .IP \fBoamf4e\fP |
||
787 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
788 | an end-to-end OAM F4 flow cell (VPI=0 & VCI=4). |
||
789 | .IP \fBoamf4\fP |
||
790 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
791 | a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)). |
||
792 | .IP \fBoam\fP |
||
793 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
794 | a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)). |
||
795 | .IP \fBmetac\fP |
||
796 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
797 | on a meta signaling circuit (VPI=0 & VCI=1). |
||
798 | .IP \fBbcc\fP |
||
799 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
800 | on a broadcast signaling circuit (VPI=0 & VCI=2). |
||
801 | .IP \fBsc\fP |
||
802 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
803 | on a signaling circuit (VPI=0 & VCI=5). |
||
804 | .IP \fBilmic\fP |
||
805 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
806 | on an ILMI circuit (VPI=0 & VCI=16). |
||
807 | .IP \fBconnectmsg\fP |
||
808 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
809 | on a signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect, |
||
810 | Connect Ack, Release, or Release Done message. |
||
811 | .IP \fBmetaconnect\fP |
||
812 | True if the packet is an ATM packet, for SunATM on Solaris, and is |
||
813 | on a meta signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect, |
||
814 | Release, or Release Done message. |
||
815 | .IP "\fIexpr relop expr\fR" |
||
816 | True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =, |
||
817 | !=, and \fIexpr\fR is an arithmetic expression composed of integer |
||
818 | constants (expressed in standard C syntax), the normal binary operators |
||
819 | [+, -, *, /, %, &, |, ^, <<, >>], a length operator, and special packet data |
||
820 | accessors. Note that all comparisons are unsigned, so that, for example, |
||
821 | 0x80000000 and 0xffffffff are > 0. |
||
822 | .IP |
||
823 | The % and ^ operators are currently only supported for filtering in the |
||
824 | kernel on Linux with 3.7 and later kernels; on all other systems, if |
||
825 | those operators are used, filtering will be done in user mode, which |
||
826 | will increase the overhead of capturing packets and may cause more |
||
827 | packets to be dropped. |
||
828 | .IP |
||
829 | To access data inside the packet, use the following syntax: |
||
830 | .in +.5i |
||
831 | .nf |
||
832 | \fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR |
||
833 | .fi |
||
834 | .in -.5i |
||
835 | \fIProto\fR is one of \fBether, fddi, tr, wlan, ppp, slip, link, |
||
836 | ip, arp, rarp, tcp, udp, icmp, ip6\fR or \fBradio\fR, and |
||
837 | indicates the protocol layer for the index operation. |
||
838 | (\fBether, fddi, wlan, tr, ppp, slip\fR and \fBlink\fR all refer to the |
||
839 | link layer. \fBradio\fR refers to the "radio header" added to some |
||
840 | 802.11 captures.) |
||
841 | Note that \fItcp, udp\fR and other upper-layer protocol types only |
||
842 | apply to IPv4, not IPv6 (this will be fixed in the future). |
||
843 | The byte offset, relative to the indicated protocol layer, is |
||
844 | given by \fIexpr\fR. |
||
845 | \fISize\fR is optional and indicates the number of bytes in the |
||
846 | field of interest; it can be either one, two, or four, and defaults to one. |
||
847 | The length operator, indicated by the keyword \fBlen\fP, gives the |
||
848 | length of the packet. |
||
849 | |||
850 | For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic. |
||
851 | The expression `\fBip[0] & 0xf != 5\fP' |
||
852 | catches all IPv4 packets with options. |
||
853 | The expression |
||
854 | `\fBip[6:2] & 0x1fff = 0\fP' |
||
855 | catches only unfragmented IPv4 datagrams and frag zero of fragmented |
||
856 | IPv4 datagrams. |
||
857 | This check is implicitly applied to the \fBtcp\fP and \fBudp\fP |
||
858 | index operations. |
||
859 | For instance, \fBtcp[0]\fP always means the first |
||
860 | byte of the TCP \fIheader\fP, and never means the first byte of an |
||
861 | intervening fragment. |
||
862 | |||
863 | Some offsets and field values may be expressed as names rather than |
||
864 | as numeric values. |
||
865 | The following protocol header field offsets are |
||
866 | available: \fBicmptype\fP (ICMP type field), \fBicmpcode\fP (ICMP |
||
867 | code field), and \fBtcpflags\fP (TCP flags field). |
||
868 | |||
869 | The following ICMP type field values are available: \fBicmp-echoreply\fP, |
||
870 | \fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP, |
||
871 | \fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP, |
||
872 | \fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP, |
||
873 | \fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP, |
||
874 | \fBicmp-maskreq\fP, \fBicmp-maskreply\fP. |
||
875 | |||
876 | The following TCP flags field values are available: \fBtcp-fin\fP, |
||
877 | \fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP, |
||
878 | \fBtcp-ack\fP, \fBtcp-urg\fP. |
||
879 | .LP |
||
880 | Primitives may be combined using: |
||
881 | .IP |
||
882 | A parenthesized group of primitives and operators |
||
883 | (parentheses are special to the Shell and must be escaped). |
||
884 | .IP |
||
885 | Negation (`\fB!\fP' or `\fBnot\fP'). |
||
886 | .IP |
||
887 | Concatenation (`\fB&&\fP' or `\fBand\fP'). |
||
888 | .IP |
||
889 | Alternation (`\fB||\fP' or `\fBor\fP'). |
||
890 | .LP |
||
891 | Negation has highest precedence. |
||
892 | Alternation and concatenation have equal precedence and associate |
||
893 | left to right. |
||
894 | Note that explicit \fBand\fR tokens, not juxtaposition, |
||
895 | are now required for concatenation. |
||
896 | .LP |
||
897 | If an identifier is given without a keyword, the most recent keyword |
||
898 | is assumed. |
||
899 | For example, |
||
900 | .in +.5i |
||
901 | .nf |
||
902 | \fBnot host vs and ace\fR |
||
903 | .fi |
||
904 | .in -.5i |
||
905 | is short for |
||
906 | .in +.5i |
||
907 | .nf |
||
908 | \fBnot host vs and host ace\fR |
||
909 | .fi |
||
910 | .in -.5i |
||
911 | which should not be confused with |
||
912 | .in +.5i |
||
913 | .nf |
||
914 | \fBnot ( host vs or ace )\fR |
||
915 | .fi |
||
916 | .in -.5i |
||
917 | .SH EXAMPLES |
||
918 | .LP |
||
919 | To select all packets arriving at or departing from \fIsundown\fP: |
||
920 | .RS |
||
921 | .nf |
||
922 | \fBhost sundown\fP |
||
923 | .fi |
||
924 | .RE |
||
925 | .LP |
||
926 | To select traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR: |
||
927 | .RS |
||
928 | .nf |
||
929 | \fBhost helios and \\( hot or ace \\)\fP |
||
930 | .fi |
||
931 | .RE |
||
932 | .LP |
||
933 | To select all IP packets between \fIace\fR and any host except \fIhelios\fR: |
||
934 | .RS |
||
935 | .nf |
||
936 | \fBip host ace and not helios\fP |
||
937 | .fi |
||
938 | .RE |
||
939 | .LP |
||
940 | To select all traffic between local hosts and hosts at Berkeley: |
||
941 | .RS |
||
942 | .nf |
||
943 | .B |
||
944 | net ucb-ether |
||
945 | .fi |
||
946 | .RE |
||
947 | .LP |
||
948 | To select all ftp traffic through internet gateway \fIsnup\fP: |
||
949 | .RS |
||
950 | .nf |
||
951 | .B |
||
952 | gateway snup and (port ftp or ftp-data) |
||
953 | .fi |
||
954 | .RE |
||
955 | .LP |
||
956 | To select traffic neither sourced from nor destined for local hosts |
||
957 | (if you gateway to one other net, this stuff should never make it |
||
958 | onto your local net). |
||
959 | .RS |
||
960 | .nf |
||
961 | .B |
||
962 | ip and not net \fIlocalnet\fP |
||
963 | .fi |
||
964 | .RE |
||
965 | .LP |
||
966 | To select the start and end packets (the SYN and FIN packets) of each |
||
967 | TCP conversation that involves a non-local host. |
||
968 | .RS |
||
969 | .nf |
||
970 | .B |
||
971 | tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP |
||
972 | .fi |
||
973 | .RE |
||
974 | .LP |
||
975 | To select all IPv4 HTTP packets to and from port 80, i.e. print only |
||
976 | packets that contain data, not, for example, SYN and FIN packets and |
||
977 | ACK-only packets. (IPv6 is left as an exercise for the reader.) |
||
978 | .RS |
||
979 | .nf |
||
980 | .B |
||
981 | tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0) |
||
982 | .fi |
||
983 | .RE |
||
984 | .LP |
||
985 | To select IP packets longer than 576 bytes sent through gateway \fIsnup\fP: |
||
986 | .RS |
||
987 | .nf |
||
988 | .B |
||
989 | gateway snup and ip[2:2] > 576 |
||
990 | .fi |
||
991 | .RE |
||
992 | .LP |
||
993 | To select IP broadcast or multicast packets that were |
||
994 | .I not |
||
995 | sent via Ethernet broadcast or multicast: |
||
996 | .RS |
||
997 | .nf |
||
998 | .B |
||
999 | ether[0] & 1 = 0 and ip[16] >= 224 |
||
1000 | .fi |
||
1001 | .RE |
||
1002 | .LP |
||
1003 | To select all ICMP packets that are not echo requests/replies (i.e., not |
||
1004 | ping packets): |
||
1005 | .RS |
||
1006 | .nf |
||
1007 | .B |
||
1008 | icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply |
||
1009 | .fi |
||
1010 | .RE |
||
1011 | .SH "SEE ALSO" |
||
1012 | pcap(3PCAP) |
||
1013 | .SH BUGS |
||
1014 | Please send problems, bugs, questions, desirable enhancements, etc. to: |
||
1015 | .LP |
||
1016 | .RS |
||
1017 | tcpdump-workers@lists.tcpdump.org |
||
1018 | .RE |
||
1019 | .LP |
||
1020 | Filter expressions on fields other than those in Token Ring headers will |
||
1021 | not correctly handle source-routed Token Ring packets. |
||
1022 | .LP |
||
1023 | Filter expressions on fields other than those in 802.11 headers will not |
||
1024 | correctly handle 802.11 data packets with both To DS and From DS set. |
||
1025 | .LP |
||
1026 | .BR "ip6 proto" |
||
1027 | should chase header chain, but at this moment it does not. |
||
1028 | .BR "ip6 protochain" |
||
1029 | is supplied for this behavior. |
||
1030 | .LP |
||
1031 | Arithmetic expression against transport layer headers, like \fBtcp[0]\fP, |
||
1032 | does not work against IPv6 packets. |
||
1033 | It only looks at IPv4 packets. |