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

NAME

6       wireshark-filter - Wireshark filter syntax and reference
7

SYNOPSIS

9       wireshark [other options] [ -R "filter expression" ]
10
11       tshark [other options] [ -R "filter expression" ]
12

DESCRIPTION

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 <https://www.wireshark.org/docs/dfref/>.
27

FILTER SYNTAX

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

FILTER FIELD REFERENCE

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

NOTES

432       The wireshark-filters manpage is part of the Wireshark distribution.
433       The latest version of Wireshark can be found at
434       <https://www.wireshark.org>.
435
436       Regular expressions in the "matches" operator are provided by GRegex in
437       GLib.  See
438       <http://developer.gnome.org/glib/2.32/glib-regex-syntax.html> or
439       <http://www.pcre.org/> for more information.
440
441       This manpage does not describe the capture filter syntax, which is
442       different. See the manual page of pcap-filter(7) or, if that doesn't
443       exist, tcpdump(8), or, if that doesn't exist,
444       <https://wiki.wireshark.org/CaptureFilters> for a description of
445       capture filters.
446

SEE ALSO

448       wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or
449       tcpdump(8) if it doesn't exist.
450

AUTHORS

452       See the list of authors in the Wireshark man page for a list of authors
453       of that code.
454
455
456
4573.0.5                             2019-10-30               WIRESHARK-FILTER(4)
Impressum