1WIRESHARK-FILTER(4)     The Wireshark Network Analyzer     WIRESHARK-FILTER(4)
2
3
4

NAME

6       wireshark-filter - Wireshark display filter syntax and reference
7

SYNOPSIS

9       wireshark [other options]
10       [ -Y "display filter expression" | b<--display-filter "display filter
11       expression" ]>
12
13       tshark [other options] [ -Y "display filter expression" ]
14

DESCRIPTION

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
24       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

FILTER SYNTAX

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
34       protocol, the filter would be "ip" (without the quotation marks). To
35       see all packets that contain a Token-Ring RIF field, use "tr.rif".
36
37       Think of a protocol or field in a filter as implicitly having the
38       "exists" operator.
39
40   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
45           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
52   Search and match operators
53       Additional operators exist expressed only in English, not C-like
54       syntax:
55
56           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
60       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
64       URL in a capture, the following filter can be used:
65
66           http contains "https://www.wireshark.org"
67
68       The "contains" operator cannot be used on atomic fields, such as
69       numbers or IP addresses.
70
71       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
77           wsp.user_agent matches "cldc"
78
79       This would match "cldc", "CLDC", "cLdC" or any other combination of
80       upper and lower case letters.
81
82       You can force case sensitivity using
83
84           wsp.user_agent matches "(?-i)cldc"
85
86       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 pcrepattern(3) man page at
89       <https://perldoc.perl.org/perlre.html>).
90
91   Functions
92       The filter language has the following functions:
93
94           upper(string-field) - converts a string field to uppercase
95           lower(string-field) - converts a string field to lowercase
96           len(field)          - returns the byte length of a string or bytes field
97           count(field)        - returns the number of field occurrences in a frame
98           string(field)       - converts a non-string field to string
99
100       upper() and lower() are useful for performing case-insensitive string
101       comparisons. For example:
102
103           upper(ncp.nds_stream_name) contains "MACRO"
104           lower(mount.dump.hostname) == "angel"
105
106       string() converts a field value to a string, suitable for use with
107       operators like "matches" or "contains". Integer fields are converted to
108       their decimal representation.  It can be used with IP/Ethernet
109       addresses (as well as others), but not with string or byte fields. For
110       example:
111
112           string(frame.number) matches "[13579]$"
113
114       gives you all the odd packets.
115
116   Protocol field types
117       Each protocol field is typed. The types are:
118
119           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
141       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
145           frame.pkt_len > 10
146           frame.pkt_len > 012
147           frame.pkt_len > 0xa
148           frame.pkt_len > '\n'
149           frame.pkt_len > '\xa'
150           frame.pkt_len > '\012'
151
152       Boolean values are either true or false.  In a display filter
153       expression testing the value of a Boolean field, "true" is expressed as
154       1 or any other non-zero value, and "false" is expressed as zero.  For
155       example, a token-ring packet's source route field is Boolean.  To find
156       any source-routed packets, a display filter would be:
157
158           tr.sr == 1
159
160       Non source-routed packets can be found with:
161
162           tr.sr == 0
163
164       Ethernet addresses and byte arrays are represented by hex digits.  The
165       hex digits may be separated by colons, periods, or hyphens:
166
167           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
172       IPv4 addresses can be represented in either dotted decimal notation or
173       by using the hostname:
174
175           ip.dst eq www.mit.edu
176           ip.src == 192.168.1.1
177
178       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
180       host order, so you do not have to worry about the endianness of an IPv4
181       address when using it in a display filter.
182
183       Classless InterDomain Routing (CIDR) notation can be used to test if an
184       IPv4 address is in a certain subnet.  For example, this display filter
185       will find all packets in the 129.111 Class-B network:
186
187           ip.addr == 129.111.0.0/16
188
189       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 Class
192       C network as 'sneezy':
193
194           ip.addr eq sneezy/24
195
196       The CIDR notation can only be used on IP addresses or hostnames, not in
197       variable names.  So, a display filter like "ip.src/24 == ip.dst/24" is
198       not valid (yet).
199
200       IPX networks are represented by unsigned 32-bit integers.  Most likely
201       you will be using hexadecimal when testing IPX network values:
202
203           ipx.src.net == 0xc0a82c00
204
205       Strings are enclosed in double quotes:
206
207           http.request.method == "POST"
208
209       Inside double quotes, you may use a backslash to embed a double quote
210       or an arbitrary byte represented in either octal or hexadecimal.
211
212           browser.comment == "An embedded \" double-quote"
213
214       Use of hexadecimal to look for "HEAD":
215
216           http.request.method == "\x48EAD"
217
218       Use of octal to look for "HEAD":
219
220           http.request.method == "\110EAD"
221
222       This means that you must escape backslashes with backslashes inside
223       double quotes.
224
225           smb.path contains "\\\\SERVER\\SHARE"
226
227       looks for \\SERVER\SHARE in "smb.path".
228
229   The slice operator
230       You can take a slice of a field if the field is a text string or a byte
231       array.  For example, you can filter on the vendor portion of an
232       ethernet address (the first three bytes) like this:
233
234           eth.src[0:3] == 00:00:83
235
236       Another example is:
237
238           http.content_type[0:4] == "text"
239
240       You can use the slice operator on a protocol name, too.  The "frame"
241       protocol can be useful, encompassing all the data captured by Wireshark
242       or TShark.
243
244           token[0:5] ne 0.0.0.1.1
245           llc[0] eq aa
246           frame[100-199] contains "wireshark"
247
248       The following syntax governs slices:
249
250           [i:j]    i = start_offset, j = length
251           [i-j]    i = start_offset, j = end_offset, inclusive.
252           [i]      i = start_offset, length = 1
253           [:j]     start_offset = 0, length = j
254           [i:]     start_offset = i, end_offset = end_of_field
255
256       Offsets can be negative, in which case they indicate the offset from
257       the end of the field.  The last byte of the field is at offset -1, the
258       last but one byte is at offset -2, and so on.  Here's how to check the
259       last four bytes of a frame:
260
261           frame[-4:4] == 0.1.2.3
262
263       or
264
265           frame[-4:] == 0.1.2.3
266
267       A slice is always compared against either a string or a byte sequence.
268       As a special case, when the slice is only 1 byte wide, you can compare
269       it against a hex integer that 0xff or less (which means it fits inside
270       one byte). This is not allowed for byte sequences greater than one
271       byte, because then one would need to specify the endianness of the
272       multi-byte integer. Also, this is not allowed for decimal numbers,
273       since they would be confused with hex numbers that are already allowed
274       as byte strings. Nevertheless, single-byte hex integers can be
275       convenient:
276
277           frame[4] == 0xff
278
279       Slices can be combined. You can concatenate them using the comma
280       operator:
281
282           ftp[1,3-5,9:] == 01:03:04:05:09:0a:0b
283
284       This concatenates offset 1, offsets 3-5, and offset 9 to the end of the
285       ftp data.
286
287   The membership operator
288       A field may be checked for matches against a set of values simply with
289       the membership operator. For instance, you may find traffic on common
290       HTTP/HTTPS ports with the following filter:
291
292           tcp.port in {80 443 8080}
293
294       as opposed to the more verbose:
295
296           tcp.port == 80 or tcp.port == 443 or tcp.port == 8080
297
298       To find HTTP requests using the HEAD or GET methods:
299
300           http.request.method in {"HEAD" "GET"}
301
302       The set of values can also contain ranges:
303
304           tcp.port in {443 4430..4434}
305           ip.addr in {10.0.0.5 .. 10.0.0.9 192.168.1.1..192.168.1.9}
306           frame.time_delta in {10 .. 10.5}
307
308   Type conversions
309       If a field is a text string or a byte array, it can be expressed in
310       whichever way is most convenient.
311
312       So, for instance, the following filters are equivalent:
313
314           http.request.method == "GET"
315           http.request.method == 47.45.54
316
317       A range can also be expressed in either way:
318
319           frame[60:2] gt 50.51
320           frame[60:2] gt "PQ"
321
322   Bit field operations
323       It is also possible to define tests with bit field operations.
324       Currently the following bit field operation is supported:
325
326           bitwise_and, &      Bitwise AND
327
328       The bitwise AND operation allows testing to see if one or more bits are
329       set.  Bitwise AND operates on integer protocol fields and slices.
330
331       When testing for TCP SYN packets, you can write:
332
333           tcp.flags & 0x02
334
335       That expression will match all packets that contain a "tcp.flags" field
336       with the 0x02 bit, i.e. the SYN bit, set.
337
338       Similarly, filtering for all WSP GET and extended GET methods is
339       achieved with:
340
341           wsp.pdu_type & 0x40
342
343       When using slices, the bit mask must be specified as a byte string, and
344       it must have the same number of bytes as the slice itself, as in:
345
346           ip[42:2] & 40:ff
347
348   Logical expressions
349       Tests can be combined using logical expressions.  These too are
350       expressible in C-like syntax or with English-like abbreviations:
351
352           and, &&   Logical AND
353           or,  ||   Logical OR
354           not, !    Logical NOT
355
356       Expressions can be grouped by parentheses as well.  The following are
357       all valid display filter expressions:
358
359           tcp.port == 80 and ip.src == 192.168.2.1
360           not llc
361           http and frame[100-199] contains "wireshark"
362           (ipx.src.net == 0xbad && ipx.src.node == 0.0.0.0.0.1) || ip
363
364       Remember that whenever a protocol or field name occurs in an
365       expression, the "exists" operator is implicitly called. The "exists"
366       operator has the highest priority. This means that the first filter
367       expression must be read as "show me the packets for which tcp.port
368       exists and equals 80, and ip.src exists and equals 192.168.2.1". The
369       second filter expression means "show me the packets where not (llc
370       exists)", or in other words "where llc does not exist" and hence will
371       match all packets that do not contain the llc protocol.  The third
372       filter expression includes the constraint that offset 199 in the frame
373       exists, in other words the length of the frame is at least 200.
374
375       A special caveat must be given regarding fields that occur more than
376       once per packet.  "ip.addr" occurs twice per IP packet, once for the
377       source address, and once for the destination address.  Likewise,
378       "tr.rif.ring" fields can occur more than once per packet.  The
379       following two expressions are not equivalent:
380
381               ip.addr ne 192.168.4.1
382           not ip.addr eq 192.168.4.1
383
384       The first filter says "show me packets where an ip.addr exists that
385       does not equal 192.168.4.1".  That is, as long as one ip.addr in the
386       packet does not equal 192.168.4.1, the packet passes the display
387       filter.  The other ip.addr could equal 192.168.4.1 and the packet would
388       still be displayed.  The second filter says "don't show me any packets
389       that have an ip.addr field equal to 192.168.4.1".  If one ip.addr is
390       192.168.4.1, the packet does not pass.  If neither ip.addr field is
391       192.168.4.1, then the packet is displayed.
392
393       It is easy to think of the 'ne' and 'eq' operators as having an
394       implicit "exists" modifier when dealing with multiply-recurring fields.
395       "ip.addr ne 192.168.4.1" can be thought of as "there exists an ip.addr
396       that does not equal 192.168.4.1".  "not ip.addr eq 192.168.4.1" can be
397       thought of as "there does not exist an ip.addr equal to 192.168.4.1".
398
399       Be careful with multiply-recurring fields; they can be confusing.
400
401       Care must also be taken when using the display filter to remove noise
402       from the packet trace. If, for example, you want to filter out all IP
403       multicast packets to address 224.1.2.3, then using:
404
405           ip.dst ne 224.1.2.3
406
407       may be too restrictive. Filtering with "ip.dst" selects only those IP
408       packets that satisfy the rule. Any other packets, including all non-IP
409       packets, will not be displayed. To display the non-IP packets as well,
410       you can use one of the following two expressions:
411
412           not ip or ip.dst ne 224.1.2.3
413           not ip.addr eq 224.1.2.3
414
415       The first filter uses "not ip" to include all non-IP packets and then
416       lets "ip.dst ne 224.1.2.3" filter out the unwanted IP packets. The
417       second filter has already been explained above where filtering with
418       multiply occurring fields was discussed.
419

FILTER FIELD REFERENCE

421       The entire list of display filters is too large to list here. You can
422       can find references and examples at the following locations:
423
424       ·   The online Display Filter Reference:
425           <https://www.wireshark.org/docs/dfref/>
426
427       ·   Help:Supported Protocols in Wireshark
428
429       ·   "tshark -G fields" on the command line
430
431       ·   The Wireshark wiki:
432           <https://gitlab.com/wireshark/wireshark/-/wikis/DisplayFilters>
433

NOTES

435       The wireshark-filters manpage is part of the Wireshark distribution.
436       The latest version of Wireshark can be found at
437       <https://www.wireshark.org>.
438
439       Regular expressions in the "matches" operator are provided by GRegex in
440       GLib.  See
441       <https://developer.gnome.org/glib/2.32/glib-regex-syntax.html> or
442       <https://www.pcre.org/> for more information.
443
444       This manpage does not describe the capture filter syntax, which is
445       different. See the manual page of pcap-filter(7) or, if that doesn't
446       exist, tcpdump(8), or, if that doesn't exist,
447       <https://gitlab.com/wireshark/wireshark/-/wikis/CaptureFilters> for a
448       description of capture filters.
449
450       Display Filters are also described in the User's Guide:
451       <https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html>
452

SEE ALSO

454       wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or
455       tcpdump(8) if it doesn't exist.
456

AUTHORS

458       See the list of authors in the Wireshark man page for a list of authors
459       of that code.
460
461
462
4633.4.4                             2021-03-16               WIRESHARK-FILTER(4)
Impressum