1WIRESHARK-FILTER(4) The Wireshark Network Analyzer WIRESHARK-FILTER(4)
2
6 wireshark-filter - Wireshark filter syntax and reference
7
9 wireshark [other options] [ -R "filter expression" ]
10 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 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 <https://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 Think of a protocol or field in a filter as implicitly having the
36 "exists" operator.
37 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 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 Search and match operators
51 Additional operators exist expressed only in English, not C-like
52 syntax:
53 contains Does the protocol, field or slice contain a value
55 matches, ~ Does the protocol or text string match the given
56 case-insensitive Perl-compatible regular expression
57 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, or for a single character, expressed as a
61 C-style character constant. For example, to search for a given HTTP
62 URL in a capture, the following filter can be used:
63 http contains "https://www.wireshark.org"
65 The "contains" operator cannot be used on atomic fields, such as
67 numbers or IP addresses.
68 The "matches" or "~" operator allows a filter to apply to a specified
70 Perl-compatible regular expression (PCRE). The "matches" operator is
71 only implemented for protocols and for protocol fields with a text
72 string representation. Matches are case-insensitive by default. For
73 example, to search for a given WAP WSP User-Agent, you can write:
74 wsp.user_agent matches "cldc"
76 This would match "cldc", "CLDC", "cLdC" or any other combination of
78 upper and lower case letters.
79 You can force case sensitivity using
81 wsp.user_agent matches "(?-i)cldc"
83 This is an example of PCRE's (?option) construct. (?-i) performs a
85 case-sensitive pattern match but other options can be specified as
86 well. More information can be found in the pcrepattern(3) man page at
87 <http://perldoc.perl.org/perlre.html>).
88 Functions
90 The filter language has the following functions:
91 upper(string-field) - converts a string field to uppercase
93 lower(string-field) - converts a string field to lowercase
94 upper() and lower() are useful for performing case-insensitive string
96 comparisons. For example:
97 upper(ncp.nds_stream_name) contains "MACRO"
99 lower(mount.dump.hostname) == "angel"
100 Protocol field types
102 Each protocol field is typed. The types are:
103 ASN.1 object identifier
105 Boolean
106 Character string
107 Compiled Perl-Compatible Regular Expression (GRegex) object
108 Date and time
109 Ethernet or other MAC address
110 EUI64 address
111 Floating point (double-precision)
112 Floating point (single-precision)
113 Frame number
114 Globally Unique Identifier
115 IPv4 address
116 IPv6 address
117 IPX network number
118 Label
119 Protocol
120 Sequence of bytes
121 Signed integer, 1, 2, 3, 4, or 8 bytes
122 Time offset
123 Unsigned integer, 1, 2, 3, 4, or 8 bytes
124 1-byte ASCII character
125 An integer may be expressed in decimal, octal, or hexadecimal notation,
127 or as a C-style character constant. The following six display filters
128 are equivalent:
129 frame.pkt_len > 10
131 frame.pkt_len > 012
132 frame.pkt_len > 0xa
133 frame.pkt_len > '\n'
134 frame.pkt_len > '\xa'
135 frame.pkt_len > '\012'
136 Boolean values are either true or false. In a display filter
138 expression testing the value of a Boolean field, "true" is expressed as
139 1 or any other non-zero value, and "false" is expressed as zero. For
140 example, a token-ring packet's source route field is Boolean. To find
141 any source-routed packets, a display filter would be:
142 tr.sr == 1
144 Non source-routed packets can be found with:
146 tr.sr == 0
148 Ethernet addresses and byte arrays are represented by hex digits. The
150 hex digits may be separated by colons, periods, or hyphens:
151 eth.dst eq ff:ff:ff:ff:ff:ff
153 aim.data == 0.1.0.d
154 fddi.src == aa-aa-aa-aa-aa-aa
155 echo.data == 7a
156 IPv4 addresses can be represented in either dotted decimal notation or
158 by using the hostname:
159 ip.dst eq www.mit.edu
161 ip.src == 192.168.1.1
162 IPv4 addresses can be compared with the same logical relations as
164 numbers: eq, ne, gt, ge, lt, and le. The IPv4 address is stored in
165 host order, so you do not have to worry about the endianness of an IPv4
166 address when using it in a display filter.
167 Classless InterDomain Routing (CIDR) notation can be used to test if an
169 IPv4 address is in a certain subnet. For example, this display filter
170 will find all packets in the 129.111 Class-B network:
171 ip.addr == 129.111.0.0/16
173 Remember, the number after the slash represents the number of bits used
175 to represent the network. CIDR notation can also be used with
176 hostnames, as in this example of finding IP addresses on the same Class
177 C network as 'sneezy':
178 ip.addr eq sneezy/24
180 The CIDR notation can only be used on IP addresses or hostnames, not in
182 variable names. So, a display filter like "ip.src/24 == ip.dst/24" is
183 not valid (yet).
184 IPX networks are represented by unsigned 32-bit integers. Most likely
186 you will be using hexadecimal when testing IPX network values:
187 ipx.src.net == 0xc0a82c00
189 Strings are enclosed in double quotes:
191 http.request.method == "POST"
193 Inside double quotes, you may use a backslash to embed a double quote
195 or an arbitrary byte represented in either octal or hexadecimal.
196 browser.comment == "An embedded \" double-quote"
198 Use of hexadecimal to look for "HEAD":
200 http.request.method == "\x48EAD"
202 Use of octal to look for "HEAD":
204 http.request.method == "\110EAD"
206 This means that you must escape backslashes with backslashes inside
208 double quotes.
209 smb.path contains "\\\\SERVER\\SHARE"
211 looks for \\SERVER\SHARE in "smb.path".
213 The slice operator
215 You can take a slice of a field if the field is a text string or a byte
216 array. For example, you can filter on the vendor portion of an
217 ethernet address (the first three bytes) like this:
218 eth.src[0:3] == 00:00:83
220 Another example is:
222 http.content_type[0:4] == "text"
224 You can use the slice operator on a protocol name, too. The "frame"
226 protocol can be useful, encompassing all the data captured by Wireshark
227 or TShark.
228 token[0:5] ne 0.0.0.1.1
230 llc[0] eq aa
231 frame[100-199] contains "wireshark"
232 The following syntax governs slices:
234 [i:j] i = start_offset, j = length
236 [i-j] i = start_offset, j = end_offset, inclusive.
237 [i] i = start_offset, length = 1
238 [:j] start_offset = 0, length = j
239 [i:] start_offset = i, end_offset = end_of_field
240 Offsets can be negative, in which case they indicate the offset from
242 the end of the field. The last byte of the field is at offset -1, the
243 last but one byte is at offset -2, and so on. Here's how to check the
244 last four bytes of a frame:
245 frame[-4:4] == 0.1.2.3
247 or
249 frame[-4:] == 0.1.2.3
251 A slice is always compared against either a string or a byte sequence.
253 As a special case, when the slice is only 1 byte wide, you can compare
254 it against a hex integer that 0xff or less (which means it fits inside
255 one byte). This is not allowed for byte sequences greater than one
256 byte, because then one would need to specify the endianness of the
257 multi-byte integer. Also, this is not allowed for decimal numbers,
258 since they would be confused with hex numbers that are already allowed
259 as byte strings. Neverthelss, single-byte hex integers can be
260 convienent:
261 frame[4] == 0xff
263 Slices can be combined. You can concatenate them using the comma
265 operator:
266 ftp[1,3-5,9:] == 01:03:04:05:09:0a:0b
268 This concatenates offset 1, offsets 3-5, and offset 9 to the end of the
270 ftp data.
271 The membership operator
273 A field may be checked for matches against a set of values simply with
274 the membership operator. For instance, you may find traffic on common
275 HTTP/HTTPS ports with the following filter:
276 tcp.port in {80 443 8080}
278 as opposed to the more verbose:
280 tcp.port == 80 or tcp.port == 443 or tcp.port == 8080
282 To find HTTP requests using the HEAD or GET methods:
284 http.request.method in {"HEAD" "GET"}
286 The set of values can also contain ranges:
288 tcp.port in {443 4430..4434}
290 ip.addr in {10.0.0.5 .. 10.0.0.9 192.168.1.1..192.168.1.9}
291 frame.time_delta in {10 .. 10.5}
292 Type conversions
294 If a field is a text string or a byte array, it can be expressed in
295 whichever way is most convenient.
296 So, for instance, the following filters are equivalent:
298 http.request.method == "GET"
300 http.request.method == 47.45.54
301 A range can also be expressed in either way:
303 frame[60:2] gt 50.51
305 frame[60:2] gt "PQ"
306 Bit field operations
308 It is also possible to define tests with bit field operations.
309 Currently the following bit field operation is supported:
310 bitwise_and, & Bitwise AND
312 The bitwise AND operation allows testing to see if one or more bits are
314 set. Bitwise AND operates on integer protocol fields and slices.
315 When testing for TCP SYN packets, you can write:
317 tcp.flags & 0x02
319 That expression will match all packets that contain a "tcp.flags" field
321 with the 0x02 bit, i.e. the SYN bit, set.
322 Similarly, filtering for all WSP GET and extended GET methods is
324 achieved with:
325 wsp.pdu_type & 0x40
327 When using slices, the bit mask must be specified as a byte string, and
329 it must have the same number of bytes as the slice itself, as in:
330 ip[42:2] & 40:ff
332 Logical expressions
334 Tests can be combined using logical expressions. These too are
335 expressible in C-like syntax or with English-like abbreviations:
336 and, && Logical AND
338 or, || Logical OR
339 not, ! Logical NOT
340 Expressions can be grouped by parentheses as well. The following are
342 all valid display filter expressions:
343 tcp.port == 80 and ip.src == 192.168.2.1
345 not llc
346 http and frame[100-199] contains "wireshark"
347 (ipx.src.net == 0xbad && ipx.src.node == 0.0.0.0.0.1) || ip
348 Remember that whenever a protocol or field name occurs in an
350 expression, the "exists" operator is implicitly called. The "exists"
351 operator has the highest priority. This means that the first filter
352 expression must be read as "show me the packets for which tcp.port
353 exists and equals 80, and ip.src exists and equals 192.168.2.1". The
354 second filter expression means "show me the packets where not (llc
355 exists)", or in other words "where llc does not exist" and hence will
356 match all packets that do not contain the llc protocol. The third
357 filter expression includes the constraint that offset 199 in the frame
358 exists, in other words the length of the frame is at least 200.
359 A special caveat must be given regarding fields that occur more than
361 once per packet. "ip.addr" occurs twice per IP packet, once for the
362 source address, and once for the destination address. Likewise,
363 "tr.rif.ring" fields can occur more than once per packet. The
364 following two expressions are not equivalent:
365 ip.addr ne 192.168.4.1
367 not ip.addr eq 192.168.4.1
368 The first filter says "show me packets where an ip.addr exists that
370 does not equal 192.168.4.1". That is, as long as one ip.addr in the
371 packet does not equal 192.168.4.1, the packet passes the display
372 filter. The other ip.addr could equal 192.168.4.1 and the packet would
373 still be displayed. The second filter says "don't show me any packets
374 that have an ip.addr field equal to 192.168.4.1". If one ip.addr is
375 192.168.4.1, the packet does not pass. If neither ip.addr field is
376 192.168.4.1, then the packet is displayed.
377 It is easy to think of the 'ne' and 'eq' operators as having an
379 implicit "exists" modifier when dealing with multiply-recurring fields.
380 "ip.addr ne 192.168.4.1" can be thought of as "there exists an ip.addr
381 that does not equal 192.168.4.1". "not ip.addr eq 192.168.4.1" can be
382 thought of as "there does not exist an ip.addr equal to 192.168.4.1".
383 Be careful with multiply-recurring fields; they can be confusing.
385 Care must also be taken when using the display filter to remove noise
387 from the packet trace. If, for example, you want to filter out all IP
388 multicast packets to address 224.1.2.3, then using:
389 ip.dst ne 224.1.2.3
391 may be too restrictive. Filtering with "ip.dst" selects only those IP
393 packets that satisfy the rule. Any other packets, including all non-IP
394 packets, will not be displayed. To display the non-IP packets as well,
395 you can use one of the following two expressions:
396 not ip or ip.dst ne 224.1.2.3
398 not ip.addr eq 224.1.2.3
399 The first filter uses "not ip" to include all non-IP packets and then
401 lets "ip.dst ne 224.1.2.3" filter out the unwanted IP packets. The
402 second filter has already been explained above where filtering with
403 multiply occurring fields was discussed.
404
406 The entire list of display filters is too large to list here. You can
407 can find references and examples at the following locations:
408 · The online Display Filter Reference:
410 <https://www.wireshark.org/docs/dfref/>
411 · Help:Supported Protocols in Wireshark
413 · "tshark -G fields" on the command line
415 · The Wireshark wiki: <https://wiki.wireshark.org/DisplayFilters>
417
419 The wireshark-filters manpage is part of the Wireshark distribution.
420 The latest version of Wireshark can be found at
421 <https://www.wireshark.org>.
422 Regular expressions in the "matches" operator are provided by GRegex in
424 GLib. See
425 <http://developer.gnome.org/glib/2.32/glib-regex-syntax.html/> or
426 <http://www.pcre.org/> for more information.
427 This manpage does not describe the capture filter syntax, which is
429 different. See the manual page of pcap-filter(7) or, if that doesn't
430 exist, tcpdump(8), or, if that doesn't exist,
431 <https://wiki.wireshark.org/CaptureFilters> for a description of
432 capture filters.
433
435 wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or
436 tcpdump(8) if it doesn't exist.
437
439 See the list of authors in the Wireshark man page for a list of authors
440 of that code.
4412.6.2 2018-07-18 WIRESHARK-FILTER(4)