1WIRESHARK-FILTER(4) The Wireshark Network Analyzer WIRESHARK-FILTER(4)
2
3
4
6 wireshark-filter - Wireshark filter syntax and reference
7
9 wireshark [other options] [ -R "filter expression" ]
10
11 tshark [other options] [ -R "filter expression" ]
12
14 Wireshark and TShark share a powerful filter engine that helps remove
15 the noise from a packet trace and lets you see only the packets that
16 interest you. If a packet meets the requirements expressed in your
17 filter, then it is displayed in the list of packets. Display filters
18 let you compare the fields within a protocol against a specific value,
19 compare fields against fields, and check the existence of specified
20 fields or protocols.
21
22 Filters are also used by other features such as statistics generation
23 and packet list colorization (the latter is only available to
24 Wireshark). This manual page describes their syntax. A comprehensive
25 reference of filter fields can be found within Wireshark and in the
26 display filter reference at <http://www.wireshark.org/docs/dfref/>.
27
29 Check whether a field or protocol exists
30 The simplest filter allows you to check for the existence of a protocol
31 or field. If you want to see all packets which contain the IP
32 protocol, the filter would be "ip" (without the quotation marks). To
33 see all packets that contain a Token-Ring RIF field, use "tr.rif".
34
35 Think of a protocol or field in a filter as implicitly having the
36 "exists" operator.
37
38 Comparison operators
39 Fields can also be compared against values. The comparison operators
40 can be expressed either through English-like abbreviations or through
41 C-like symbols:
42
43 eq, == Equal
44 ne, != Not Equal
45 gt, > Greater Than
46 lt, < Less Than
47 ge, >= Greater than or Equal to
48 le, <= Less than or Equal to
49
50 Search and match operators
51 Additional operators exist expressed only in English, not C-like
52 syntax:
53
54 contains Does the protocol, field or slice contain a value
55 matches Does the protocol or text string match the given Perl
56 regular expression
57
58 The "contains" operator allows a filter to search for a sequence of
59 characters, expressed as a string (quoted or unquoted), or bytes,
60 expressed as a byte array. For example, to search for a given HTTP URL
61 in a capture, the following filter can be used:
62
63 http contains "http://www.wireshark.org"
64
65 The "contains" operator cannot be used on atomic fields, such as
66 numbers or IP addresses.
67
68 The "matches" operator allows a filter to apply to a specified Perl-
69 compatible regular expression (PCRE). The "matches" operator is only
70 implemented for protocols and for protocol fields with a text string
71 representation. For example, to search for a given WAP WSP User-Agent,
72 you can write:
73
74 wsp.user_agent matches "(?i)cldc"
75
76 This example shows an interesting PCRE feature: pattern match options
77 have to be specified with the (?option) construct. For instance, (?i)
78 performs a case-insensitive pattern match. More information on PCRE can
79 be found in the pcrepattern(3) man page (Perl Regular Expressions are
80 explained in <http://perldoc.perl.org/perlre.html>).
81
82 Functions
83 The filter language has the following functions:
84
85 upper(string-field) - converts a string field to uppercase
86 lower(string-field) - converts a string field to lowercase
87
88 upper() and lower() are useful for performing case-insensitive string
89 comparisons. For example:
90
91 upper(ncp.nds_stream_name) contains "MACRO"
92 lower(mount.dump.hostname) == "angel"
93
94 Protocol field types
95 Each protocol field is typed. The types are:
96
97 ASN.1 object identifier
98 Boolean
99 Character string
100 Compiled Perl-Compatible Regular Expression (GRegex) object
101 Date and time
102 Ethernet or other MAC address
103 EUI64 address
104 Floating point (double-precision)
105 Floating point (single-precision)
106 Frame number
107 Globally Unique Identifier
108 IPv4 address
109 IPv6 address
110 IPX network number
111 Label
112 Protocol
113 Sequence of bytes
114 Signed integer, 1, 2, 3, 4, or 8 bytes
115 Time offset
116 Unsigned integer, 1, 2, 3, 4, or 8 bytes
117
118 An integer may be expressed in decimal, octal, or hexadecimal notation.
119 The following three display filters are equivalent:
120
121 frame.pkt_len > 10
122 frame.pkt_len > 012
123 frame.pkt_len > 0xa
124
125 Boolean values are either true or false. In a display filter
126 expression testing the value of a Boolean field, "true" is expressed as
127 1 or any other non-zero value, and "false" is expressed as zero. For
128 example, a token-ring packet's source route field is Boolean. To find
129 any source-routed packets, a display filter would be:
130
131 tr.sr == 1
132
133 Non source-routed packets can be found with:
134
135 tr.sr == 0
136
137 Ethernet addresses and byte arrays are represented by hex digits. The
138 hex digits may be separated by colons, periods, or hyphens:
139
140 eth.dst eq ff:ff:ff:ff:ff:ff
141 aim.data == 0.1.0.d
142 fddi.src == aa-aa-aa-aa-aa-aa
143 echo.data == 7a
144
145 IPv4 addresses can be represented in either dotted decimal notation or
146 by using the hostname:
147
148 ip.dst eq www.mit.edu
149 ip.src == 192.168.1.1
150
151 IPv4 addresses can be compared with the same logical relations as
152 numbers: eq, ne, gt, ge, lt, and le. The IPv4 address is stored in
153 host order, so you do not have to worry about the endianness of an IPv4
154 address when using it in a display filter.
155
156 Classless InterDomain Routing (CIDR) notation can be used to test if an
157 IPv4 address is in a certain subnet. For example, this display filter
158 will find all packets in the 129.111 Class-B network:
159
160 ip.addr == 129.111.0.0/16
161
162 Remember, the number after the slash represents the number of bits used
163 to represent the network. CIDR notation can also be used with
164 hostnames, as in this example of finding IP addresses on the same Class
165 C network as 'sneezy':
166
167 ip.addr eq sneezy/24
168
169 The CIDR notation can only be used on IP addresses or hostnames, not in
170 variable names. So, a display filter like "ip.src/24 == ip.dst/24" is
171 not valid (yet).
172
173 IPX networks are represented by unsigned 32-bit integers. Most likely
174 you will be using hexadecimal when testing IPX network values:
175
176 ipx.src.net == 0xc0a82c00
177
178 Strings are enclosed in double quotes:
179
180 http.request.method == "POST"
181
182 Inside double quotes, you may use a backslash to embed a double quote
183 or an arbitrary byte represented in either octal or hexadecimal.
184
185 browser.comment == "An embedded \" double-quote"
186
187 Use of hexadecimal to look for "HEAD":
188
189 http.request.method == "\x48EAD"
190
191 Use of octal to look for "HEAD":
192
193 http.request.method == "\110EAD"
194
195 This means that you must escape backslashes with backslashes inside
196 double quotes.
197
198 smb.path contains "\\\\SERVER\\SHARE"
199
200 looks for \\SERVER\SHARE in "smb.path".
201
202 The slice operator
203 You can take a slice of a field if the field is a text string or a byte
204 array. For example, you can filter on the vendor portion of an
205 ethernet address (the first three bytes) like this:
206
207 eth.src[0:3] == 00:00:83
208
209 Another example is:
210
211 http.content_type[0:4] == "text"
212
213 You can use the slice operator on a protocol name, too. The "frame"
214 protocol can be useful, encompassing all the data captured by Wireshark
215 or TShark.
216
217 token[0:5] ne 0.0.0.1.1
218 llc[0] eq aa
219 frame[100-199] contains "wireshark"
220
221 The following syntax governs slices:
222
223 [i:j] i = start_offset, j = length
224 [i-j] i = start_offset, j = end_offset, inclusive.
225 [i] i = start_offset, length = 1
226 [:j] start_offset = 0, length = j
227 [i:] start_offset = i, end_offset = end_of_field
228
229 Offsets can be negative, in which case they indicate the offset from
230 the end of the field. The last byte of the field is at offset -1, the
231 last but one byte is at offset -2, and so on. Here's how to check the
232 last four bytes of a frame:
233
234 frame[-4:4] == 0.1.2.3
235
236 or
237
238 frame[-4:] == 0.1.2.3
239
240 A slice is alwasy compared against either a string or a byte sequence.
241 As a special case, when the slice is only 1 byte wide, you can compare
242 it against a hex integer that 0xff or less (which means it fits inside
243 one byte). This is not allowed for byte sequences greater than one
244 byte, because then one would need to specify the endianness of the
245 multi-byte integer. Also, this is not allowed for decimal numbers,
246 since they would be confused with hex numbers that are already allowed
247 as byte strings. Neverthelss, single-byte hex integers can be
248 convienent:
249
250 frame[4] == 0xff
251
252 Slices can be combined. You can concatenate them using the comma
253 operator:
254
255 ftp[1,3-5,9:] == 01:03:04:05:09:0a:0b
256
257 This concatenates offset 1, offsets 3-5, and offset 9 to the end of the
258 ftp data.
259
260 Type conversions
261 If a field is a text string or a byte array, it can be expressed in
262 whichever way is most convenient.
263
264 So, for instance, the following filters are equivalent:
265
266 http.request.method == "GET"
267 http.request.method == 47.45.54
268
269 A range can also be expressed in either way:
270
271 frame[60:2] gt 50.51
272 frame[60:2] gt "PQ"
273
274 Bit field operations
275 It is also possible to define tests with bit field operations.
276 Currently the following bit field operation is supported:
277
278 bitwise_and, & Bitwise AND
279
280 The bitwise AND operation allows testing to see if one or more bits are
281 set. Bitwise AND operates on integer protocol fields and slices.
282
283 When testing for TCP SYN packets, you can write:
284
285 tcp.flags & 0x02
286
287 That expression will match all packets that contain a "tcp.flags" field
288 with the 0x02 bit, i.e. the SYN bit, set.
289
290 Similarly, filtering for all WSP GET and extended GET methods is
291 achieved with:
292
293 wsp.pdu_type & 0x40
294
295 When using slices, the bit mask must be specified as a byte string, and
296 it must have the same number of bytes as the slice itself, as in:
297
298 ip[42:2] & 40:ff
299
300 Logical expressions
301 Tests can be combined using logical expressions. These too are
302 expressible in C-like syntax or with English-like abbreviations:
303
304 and, && Logical AND
305 or, || Logical OR
306 not, ! Logical NOT
307
308 Expressions can be grouped by parentheses as well. The following are
309 all valid display filter expressions:
310
311 tcp.port == 80 and ip.src == 192.168.2.1
312 not llc
313 http and frame[100-199] contains "wireshark"
314 (ipx.src.net == 0xbad && ipx.src.node == 0.0.0.0.0.1) || ip
315
316 Remember that whenever a protocol or field name occurs in an
317 expression, the "exists" operator is implicitly called. The "exists"
318 operator has the highest priority. This means that the first filter
319 expression must be read as "show me the packets for which tcp.port
320 exists and equals 80, and ip.src exists and equals 192.168.2.1". The
321 second filter expression means "show me the packets where not (llc
322 exists)", or in other words "where llc does not exist" and hence will
323 match all packets that do not contain the llc protocol. The third
324 filter expression includes the constraint that offset 199 in the frame
325 exists, in other words the length of the frame is at least 200.
326
327 A special caveat must be given regarding fields that occur more than
328 once per packet. "ip.addr" occurs twice per IP packet, once for the
329 source address, and once for the destination address. Likewise,
330 "tr.rif.ring" fields can occur more than once per packet. The
331 following two expressions are not equivalent:
332
333 ip.addr ne 192.168.4.1
334 not ip.addr eq 192.168.4.1
335
336 The first filter says "show me packets where an ip.addr exists that
337 does not equal 192.168.4.1". That is, as long as one ip.addr in the
338 packet does not equal 192.168.4.1, the packet passes the display
339 filter. The other ip.addr could equal 192.168.4.1 and the packet would
340 still be displayed. The second filter says "don't show me any packets
341 that have an ip.addr field equal to 192.168.4.1". If one ip.addr is
342 192.168.4.1, the packet does not pass. If neither ip.addr field is
343 192.168.4.1, then the packet is displayed.
344
345 It is easy to think of the 'ne' and 'eq' operators as having an
346 implicit "exists" modifier when dealing with multiply-recurring fields.
347 "ip.addr ne 192.168.4.1" can be thought of as "there exists an ip.addr
348 that does not equal 192.168.4.1". "not ip.addr eq 192.168.4.1" can be
349 thought of as "there does not exist an ip.addr equal to 192.168.4.1".
350
351 Be careful with multiply-recurring fields; they can be confusing.
352
353 Care must also be taken when using the display filter to remove noise
354 from the packet trace. If, for example, you want to filter out all IP
355 multicast packets to address 224.1.2.3, then using:
356
357 ip.dst ne 224.1.2.3
358
359 may be too restrictive. Filtering with "ip.dst" selects only those IP
360 packets that satisfy the rule. Any other packets, including all non-IP
361 packets, will not be displayed. To display the non-IP packets as well,
362 you can use one of the following two expressions:
363
364 not ip or ip.dst ne 224.1.2.3
365 not ip.addr eq 224.1.2.3
366
367 The first filter uses "not ip" to include all non-IP packets and then
368 lets "ip.dst ne 224.1.2.3" filter out the unwanted IP packets. The
369 second filter has already been explained above where filtering with
370 multiply occurring fields was discussed.
371
373 The entire list of display filters is too large to list here. You can
374 can find references and examples at the following locations:
375
376 · The online Display Filter Reference:
377 <http://www.wireshark.org/docs/dfref/>
378
379 · Help:Supported Protocols in Wireshark
380
381 · "tshark -G fields" on the command line
382
383 · The Wireshark wiki: <http://wiki.wireshark.org/DisplayFilters>
384
386 The wireshark-filters manpage is part of the Wireshark distribution.
387 The latest version of Wireshark can be found at
388 <http://www.wireshark.org>.
389
390 Regular expressions in the "matches" operator are provided by GRegex in
391 GLib. See
392 <http://developer.gnome.org/glib/2.32/glib-regex-syntax.html/> or
393 <http://www.pcre.org/> for more information.
394
395 This manpage does not describe the capture filter syntax, which is
396 different. See the manual page of pcap-filter(7) or, if that doesn't
397 exist, tcpdump(8), or, if that doesn't exist,
398 <http://wiki.wireshark.org/CaptureFilters> for a description of capture
399 filters.
400
402 wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or
403 tcpdump(8) if it doesn't exist.
404
406 See the list of authors in the Wireshark man page for a list of authors
407 of that code.
408
409
410
4111.10.14 2015-05-12 WIRESHARK-FILTER(4)