1WIRESHARK-FILTER(4) WIRESHARK-FILTER(4)
2
6 wireshark-filter - Wireshark display filter syntax and reference
7
9 wireshark [other options] [ -Y "display filter expression" |
10 --display-filter "display filter expression" ]
11 tshark [other options] [ -Y "display filter expression" |
13 --display-filter "display filter expression" ]
14
16 Wireshark and TShark share a powerful filter engine that helps remove
17 the noise from a packet trace and lets you see only the packets that
18 interest you. If a packet meets the requirements expressed in your
19 filter, then it is displayed in the list of packets. Display filters
20 let you compare the fields within a protocol against a specific value,
21 compare fields against fields, and check the existence of specified
22 fields or protocols.
23 Filters are also used by other features such as statistics generation
25 and packet list colorization (the latter is only available to
26 Wireshark). This manual page describes their syntax. A comprehensive
27 reference of filter fields can be found within Wireshark and in the
28 display filter reference at https://www.wireshark.org/docs/dfref/.
29
31 Check whether a field or protocol exists
32 The simplest filter allows you to check for the existence of a protocol
33 or field. If you want to see all packets which contain the IP protocol,
34 the filter would be "ip" (without the quotation marks). To see all
35 packets that contain a Token-Ring RIF field, use "tr.rif".
36 Think of a protocol or field in a filter as implicitly having the
38 "exists" operator.
39 Comparison operators
41 Fields can also be compared against values. The comparison operators
42 can be expressed either through English-like abbreviations or through
43 C-like symbols:
44 eq, == Equal
46 ne, != Not Equal
47 gt, > Greater Than
48 lt, < Less Than
49 ge, >= Greater than or Equal to
50 le, <= Less than or Equal to
51 Search and match operators
53 Additional operators exist expressed only in English, not C-like
54 syntax:
55 contains Does the protocol, field or slice contain a value
57 matches, ~ Does the protocol or text string match the given
58 case-insensitive Perl-compatible regular expression
59 The "contains" operator allows a filter to search for a sequence of
61 characters, expressed as a string (quoted or unquoted), or bytes,
62 expressed as a byte array, or for a single character, expressed as a
63 C-style character constant. For example, to search for a given HTTP URL
64 in a capture, the following filter can be used:
65 http contains "https://www.wireshark.org"
67 The "contains" operator cannot be used on atomic fields, such as
69 numbers or IP addresses.
70 The "matches" or "~" operator allows a filter to apply to a specified
72 Perl-compatible regular expression (PCRE). The "matches" operator is
73 only implemented for protocols and for protocol fields with a text
74 string representation. Matches are case-insensitive by default. For
75 example, to search for a given WAP WSP User-Agent, you can write:
76 wsp.header.user_agent matches "cldc"
78 This would match "cldc", "CLDC", "cLdC" or any other combination of
80 upper and lower case letters.
81 You can force case sensitivity using
83 wsp.header.user_agent matches "(?-i)cldc"
85 This is an example of PCRE’s (?*option)* construct. (?-i) performs a
87 case-sensitive pattern match but other options can be specified as
88 well. More information can be found in the
89 pcrepattern(3)|https://www.pcre.org/original/doc/html/pcrepattern.html
90 man page.
91 Functions
93 The filter language has the following functions:
94 upper(string-field) - converts a string field to uppercase
96 lower(string-field) - converts a string field to lowercase
97 len(field) - returns the byte length of a string or bytes field
98 count(field) - returns the number of field occurrences in a frame
99 string(field) - converts a non-string field to string
100 upper() and lower() are useful for performing case-insensitive string
102 comparisons. For example:
103 upper(ncp.nds_stream_name) contains "MACRO"
105 lower(mount.dump.hostname) == "angel"
106 string() converts a field value to a string, suitable for use with
108 operators like "matches" or "contains". Integer fields are converted to
109 their decimal representation. It can be used with IP/Ethernet addresses
110 (as well as others), but not with string or byte fields. For example:
111 string(frame.number) matches "[13579]$"
113 gives you all the odd packets.
115 Protocol field types
117 Each protocol field is typed. The types are:
118 ASN.1 object identifier
120 Boolean
121 Character string
122 Compiled Perl-Compatible Regular Expression (GRegex) object
123 Date and time
124 Ethernet or other MAC address
125 EUI64 address
126 Floating point (double-precision)
127 Floating point (single-precision)
128 Frame number
129 Globally Unique Identifier
130 IPv4 address
131 IPv6 address
132 IPX network number
133 Label
134 Protocol
135 Sequence of bytes
136 Signed integer, 1, 2, 3, 4, or 8 bytes
137 Time offset
138 Unsigned integer, 1, 2, 3, 4, or 8 bytes
139 1-byte ASCII character
140 An integer may be expressed in decimal, octal, or hexadecimal notation,
142 or as a C-style character constant. The following six display filters
143 are equivalent:
144 frame.len > 10
146 frame.len > 012
147 frame.len > 0xa
148 frame.len > '\n'
149 frame.len > '\x0a'
150 frame.len > '\012'
151 Boolean values are either true or false. In a display filter expression
153 testing the value of a Boolean field, "true" is expressed as 1 or any
154 other non-zero value, and "false" is expressed as zero. For example, a
155 token-ring packet’s source route field is Boolean. To find any
156 source-routed packets, a display filter would be:
157 tr.sr == 1
159 Non source-routed packets can be found with:
161 tr.sr == 0
163 Ethernet addresses and byte arrays are represented by hex digits. The
165 hex digits may be separated by colons, periods, or hyphens:
166 eth.dst eq ff:ff:ff:ff:ff:ff
168 aim.data == 0.1.0.d
169 fddi.src == aa-aa-aa-aa-aa-aa
170 echo.data == 7a
171 IPv4 addresses can be represented in either dotted decimal notation or
173 by using the hostname:
174 ip.src == 192.168.1.1
176 ip.dst eq www.mit.edu
177 IPv4 addresses can be compared with the same logical relations as
179 numbers: eq, ne, gt, ge, lt, and le. The IPv4 address is stored in host
180 order, so you do not have to worry about the endianness of an IPv4
181 address when using it in a display filter.
182 Classless Inter-Domain Routing (CIDR) notation can be used to test if
184 an IPv4 address is in a certain subnet. For example, this display
185 filter will find all packets in the 129.111 network:
186 ip.addr == 129.111.0.0/16
188 Remember, the number after the slash represents the number of bits used
190 to represent the network. CIDR notation can also be used with
191 hostnames, as in this example of finding IP addresses on the same
192 network as 'sneezy' (requires that 'sneezy' resolve to an IP address
193 for filter to be valid):
194 ip.addr eq sneezy/24
196 The CIDR notation can only be used on IP addresses or hostnames, not in
198 variable names. So, a display filter like "ip.src/24 == ip.dst/24" is
199 not valid (yet).
200 Transaction and other IDs are often represented by unsigned 16 or 32
202 bit integers and formatted as a hexadecimal string with "0x" prefix:
203 (dhcp.id == 0xfe089c15) || (ip.id == 0x0373)
205 Strings are enclosed in double quotes:
207 http.request.method == "POST"
209 Inside double quotes, you may use a backslash to embed a double quote
211 or an arbitrary byte represented in either octal or hexadecimal.
212 browser.comment == "An embedded \" double-quote"
214 Use of hexadecimal to look for "HEAD":
216 http.request.method == "\x48EAD"
218 Use of octal to look for "HEAD":
220 http.request.method == "\110EAD"
222 This means that you must escape backslashes with backslashes inside
224 double quotes.
225 smb.path contains "\\\\SERVER\\SHARE"
227 looks for \\SERVER\SHARE in "smb.path". This may be more conveniently
229 written as
230 smb.path contains r"\\SERVER\SHARE"
232 String literals prefixed with 'r' are called "raw strings". Such
234 strings treat backslash as a literal character. Double quotes may still
235 be escaped with backslash but note that backslashes are always
236 preserved in the result.
237 The slice operator
239 You can take a slice of a field if the field is a text string or a byte
240 array. For example, you can filter on the vendor portion of an ethernet
241 address (the first three bytes) like this:
242 eth.src[0:3] == 00:00:83
244 Another example is:
246 http.content_type[0:4] == "text"
248 You can use the slice operator on a protocol name, too. The "frame"
250 protocol can be useful, encompassing all the data captured by Wireshark
251 or TShark.
252 token[0:5] ne 0.0.0.1.1
254 llc[0] eq aa
255 frame[100-199] contains "wireshark"
256 The following syntax governs slices:
258 [i:j] i = start_offset, j = length
260 [i-j] i = start_offset, j = end_offset, inclusive.
261 [i] i = start_offset, length = 1
262 [:j] start_offset = 0, length = j
263 [i:] start_offset = i, end_offset = end_of_field
264 Offsets can be negative, in which case they indicate the offset from
266 the end of the field. The last byte of the field is at offset -1, the
267 last but one byte is at offset -2, and so on. Here’s how to check the
268 last four bytes of a frame:
269 frame[-4:4] == 0.1.2.3
271 or
273 frame[-4:] == 0.1.2.3
275 A slice is always compared against either a string or a byte sequence.
277 As a special case, when the slice is only 1 byte wide, you can compare
278 it against a hex integer that is 0xff or less (which means it fits
279 inside one byte). This is not allowed for byte sequences greater than
280 one byte, because then one would need to specify the endianness of the
281 multi-byte integer. Also, this is not allowed for decimal numbers,
282 since they would be confused with hex numbers that are already allowed
283 as byte strings. Nevertheless, single-byte hex integers can be
284 convenient:
285 frame[4] == 0xff
287 Slices can be combined. You can concatenate them using the comma
289 operator:
290 ftp[1,3-5,9:] == 01:03:04:05:09:0a:0b
292 This concatenates offset 1, offsets 3-5, and offset 9 to the end of the
294 ftp data.
295 The membership operator
297 A field may be checked for matches against a set of values simply with
298 the membership operator. For instance, you may find traffic on common
299 HTTP/HTTPS ports with the following filter:
300 tcp.port in {80, 443, 8080}
302 as opposed to the more verbose:
304 tcp.port == 80 or tcp.port == 443 or tcp.port == 8080
306 To find HTTP requests using the HEAD or GET methods:
308 http.request.method in {"HEAD", "GET"}
310 The set of values can also contain ranges:
312 tcp.port in {443, 4430..4434}
314 ip.addr in {10.0.0.5 .. 10.0.0.9, 192.168.1.1..192.168.1.9}
315 frame.time_delta in {10 .. 10.5}
316 Type conversions
318 If a field is a text string or a byte array, it can be expressed in
319 whichever way is most convenient.
320 So, for instance, the following filters are equivalent:
322 http.request.method == "GET"
324 http.request.method == 47.45.54
325 A range can also be expressed in either way:
327 frame[60:2] gt 50.51
329 frame[60:2] gt "PQ"
330 Bit field operations
332 It is also possible to define tests with bit field operations.
333 Currently the following bit field operation is supported:
334 bitwise_and, & Bitwise AND
336 The bitwise AND operation allows testing to see if one or more bits are
338 set. Bitwise AND operates on integer protocol fields and slices.
339 When testing for TCP SYN packets, you can write:
341 tcp.flags & 0x02
343 That expression will match all packets that contain a "tcp.flags" field
345 with the 0x02 bit, i.e. the SYN bit, set.
346 Similarly, filtering for all WSP GET and extended GET methods is
348 achieved with:
349 wsp.pdu_type & 0x40
351 When using slices, the bit mask must be specified as a byte string, and
353 it must have the same number of bytes as the slice itself, as in:
354 ip[42:2] & 40:ff
356 Logical expressions
358 Tests can be combined using logical expressions. These too are
359 expressible in C-like syntax or with English-like abbreviations:
360 and, && Logical AND
362 or, || Logical OR
363 not, ! Logical NOT
364 Expressions can be grouped by parentheses as well. The following are
366 all valid display filter expressions:
367 tcp.port == 80 and ip.src == 192.168.2.1
369 not llc
370 http and frame[100-199] contains "wireshark"
371 (ipx.src.net == 0xbad && ipx.src.node == 0.0.0.0.0.1) || ip
372 Remember that whenever a protocol or field name occurs in an
374 expression, the "exists" operator is implicitly called. The "exists"
375 operator has the highest priority. This means that the first filter
376 expression must be read as "show me the packets for which tcp.port
377 exists and equals 80, and ip.src exists and equals 192.168.2.1". The
378 second filter expression means "show me the packets where not exists
379 llc", or in other words "where llc does not exist" and hence will match
380 all packets that do not contain the llc protocol. The third filter
381 expression includes the constraint that offset 199 in the frame exists,
382 in other words the length of the frame is at least 200.
383 Each comparison has an implicit exists test for any field value. Care
385 must be taken when using the display filter to remove noise from the
386 packet trace. If, for example, you want to filter out all IP multicast
387 packets to address 224.1.2.3, then using:
388 ip.dst ne 224.1.2.3
390 may be too restrictive. This is the same as writing:
392 ip.dst and ip.dst ne 224.1.2.3
394 The filter selects only frames that have the "ip.dst" field. Any other
396 frames, including all non-IP packets, will not be displayed. To display
397 the non-IP packets as well, you can use one of the following two
398 expressions:
399 not ip.dst or ip.dst ne 224.1.2.3
401 not ip.dst eq 224.1.2.3
402 The first filter uses "not ip.dst" to include all non-IP packets and
404 then lets "ip.dst ne 224.1.2.3" filter out the unwanted IP packets. The
405 second filter also negates the implicit existance test and so is a
406 shorter way to write the first.
407
409 The entire list of display filters is too large to list here. You can
410 can find references and examples at the following locations:
411 • The online Display Filter Reference:
413 https://www.wireshark.org/docs/dfref/
414 • View:Internals:Supported Protocols in Wireshark
416 • tshark -G fields on the command line
418 • The Wireshark wiki:
420 https://gitlab.com/wireshark/wireshark/-/wikis/DisplayFilters
421
423 The wireshark-filter(4) manpage is part of the Wireshark distribution.
424 The latest version of Wireshark can be found at
425 https://www.wireshark.org.
426 Regular expressions in the "matches" operator are provided by GRegex in
428 GLib. See
429 https://developer-old.gnome.org/glib/stable/glib-regex-syntax.html or
430 https://www.pcre.org/ for more information.
431 This manpage does not describe the capture filter syntax, which is
433 different. See the manual page of pcap-filter(7) or, if that doesn’t
434 exist, tcpdump(8), or, if that doesn’t exist,
435 https://gitlab.com/wireshark/wireshark/-/wikis/CaptureFilters for a
436 description of capture filters.
437 Display Filters are also described in the User’s Guide:
439 https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html
440
442 wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or
443 tcpdump(8) if it doesn’t exist.
444
446 See the list of authors in the Wireshark man page for a list of authors
447 of that code.
448 2021-11-25 WIRESHARK-FILTER(4)