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

FILTER FIELD REFERENCE

383       The entire list of display filters is too large to list here. You can
384       can find references and examples at the following locations:
385
386       ·   The online Display Filter Reference:
387           <http://www.wireshark.org/docs/dfref/>
388
389       ·   Help:Supported Protocols in Wireshark
390
391       ·   "tshark -G fields" on the command line
392
393       ·   The Wireshark wiki: <http://wiki.wireshark.org/DisplayFilters>
394

NOTES

396       The wireshark-filters manpage is part of the Wireshark distribution.
397       The latest version of Wireshark can be found at
398       <http://www.wireshark.org>.
399
400       Regular expressions in the "matches" operator are provided with
401       libpcre, the Perl-Compatible Regular Expressions library: see
402       http://www.pcre.org/.
403
404       This manpage does not describe the capture filter syntax, which is
405       different. See the manual page of pcap-filter(7) or, if that doesn't
406       exist, tcpdump(8), or, if that doesn't exist,
407       <http://wiki.wireshark.org/CaptureFilters> for a description of capture
408       filters.
409

SEE ALSO

411       wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or
412       tcpdump(8) if it doesn't exist.
413

AUTHORS

415       See the list of authors in the Wireshark man page for a list of authors
416       of that code.
417
418
419
4201.8.10                            2013-07-23               WIRESHARK-FILTER(4)
Impressum