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 <http://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 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

FILTER FIELD REFERENCE

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

NOTES

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

SEE ALSO

402       wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or
403       tcpdump(8) if it doesn't exist.
404

AUTHORS

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)
Impressum