2012-06-19 15:44:10 +00:00
|
|
|
|
2003-10-01 14:59:41 +00:00
|
|
|
=head1 NAME
|
|
|
|
|
2006-05-31 19:12:15 +00:00
|
|
|
wireshark-filter - Wireshark filter syntax and reference
|
2003-10-01 14:59:41 +00:00
|
|
|
|
2009-05-12 21:10:38 +00:00
|
|
|
=head1 SYNOPSIS
|
2003-10-01 14:59:41 +00:00
|
|
|
|
2006-05-31 19:12:15 +00:00
|
|
|
B<wireshark> [other options]
|
2003-10-01 14:59:41 +00:00
|
|
|
S<[ B<-R> "filter expression" ]>
|
|
|
|
|
2006-05-31 17:38:42 +00:00
|
|
|
B<tshark> [other options]
|
2003-10-01 14:59:41 +00:00
|
|
|
S<[ B<-R> "filter expression" ]>
|
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
2006-05-31 19:12:15 +00:00
|
|
|
B<Wireshark> and B<TShark> share a powerful filter engine that helps remove
|
2004-06-03 07:37:49 +00:00
|
|
|
the noise from a packet trace and lets you see only the packets that interest
|
2003-10-15 02:13:33 +00:00
|
|
|
you. If a packet meets the requirements expressed in your filter, then it
|
|
|
|
is displayed in the list of packets. Display filters let you compare the
|
|
|
|
fields within a protocol against a specific value, compare fields against
|
2004-06-03 07:37:49 +00:00
|
|
|
fields, and check the existence of specified fields or protocols.
|
2003-10-01 14:59:41 +00:00
|
|
|
|
2003-10-15 02:13:33 +00:00
|
|
|
Filters are also used by other features such as statistics generation and
|
2006-05-31 19:12:15 +00:00
|
|
|
packet list colorization (the latter is only available to B<Wireshark>). This
|
2010-11-30 17:46:09 +00:00
|
|
|
manual page describes their syntax. A comprehensive reference of filter fields
|
|
|
|
can be found within Wireshark and in the display filter reference at
|
2014-09-17 00:08:53 +00:00
|
|
|
L<https://www.wireshark.org/docs/dfref/>.
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
=head1 FILTER SYNTAX
|
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
=head2 Check whether a field or protocol exists
|
|
|
|
|
2003-10-15 02:13:33 +00:00
|
|
|
The simplest filter allows you to check for the existence of a protocol or
|
2005-10-30 13:46:40 +00:00
|
|
|
field. If you want to see all packets which contain the IP protocol, the
|
|
|
|
filter would be "ip" (without the quotation marks). To see all packets
|
2003-10-15 02:13:33 +00:00
|
|
|
that contain a Token-Ring RIF field, use "tr.rif".
|
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
Think of a protocol or field in a filter as implicitly having the "exists"
|
|
|
|
operator.
|
|
|
|
|
|
|
|
=head2 Comparison operators
|
|
|
|
|
2003-10-15 02:13:33 +00:00
|
|
|
Fields can also be compared against values. The comparison operators
|
2013-06-07 17:06:27 +00:00
|
|
|
can be expressed either through English-like abbreviations or through
|
2005-10-30 13:46:40 +00:00
|
|
|
C-like symbols:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
eq, == Equal
|
2004-06-03 07:37:49 +00:00
|
|
|
ne, != Not Equal
|
|
|
|
gt, > Greater Than
|
2003-10-15 02:13:33 +00:00
|
|
|
lt, < Less Than
|
|
|
|
ge, >= Greater than or Equal to
|
|
|
|
le, <= Less than or Equal to
|
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
=head2 Search and match operators
|
|
|
|
|
2005-10-31 03:45:11 +00:00
|
|
|
Additional operators exist expressed only in English, not C-like syntax:
|
2003-12-07 18:32:59 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
contains Does the protocol, field or slice contain a value
|
2005-10-31 03:45:11 +00:00
|
|
|
matches Does the protocol or text string match the given Perl
|
|
|
|
regular expression
|
2003-12-07 18:32:59 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
The "contains" operator allows a filter to search for a sequence of
|
2005-10-31 03:45:11 +00:00
|
|
|
characters, expressed as a string (quoted or unquoted), or bytes,
|
2016-09-19 01:48:50 +00:00
|
|
|
expressed as a byte array, or for a single character, expressed as a
|
|
|
|
C-style character constant. For example, to search for a given HTTP
|
2003-12-07 18:32:59 +00:00
|
|
|
URL in a capture, the following filter can be used:
|
|
|
|
|
2014-09-17 00:08:53 +00:00
|
|
|
http contains "https://www.wireshark.org"
|
2004-06-03 07:37:49 +00:00
|
|
|
|
|
|
|
The "contains" operator cannot be used on atomic fields,
|
|
|
|
such as numbers or IP addresses.
|
2003-12-07 18:32:59 +00:00
|
|
|
|
2003-12-08 22:24:36 +00:00
|
|
|
The "matches" operator allows a filter to apply to a specified
|
2003-12-17 23:24:49 +00:00
|
|
|
Perl-compatible regular expression (PCRE). The "matches" operator is only
|
2004-06-03 07:37:49 +00:00
|
|
|
implemented for protocols and for protocol fields with a text string
|
2003-12-17 23:24:49 +00:00
|
|
|
representation. For example, to search for a given WAP WSP User-Agent,
|
2004-06-03 07:37:49 +00:00
|
|
|
you can write:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
wsp.user_agent matches "(?i)cldc"
|
2003-12-07 18:32:59 +00:00
|
|
|
|
|
|
|
This example shows an interesting PCRE feature: pattern match options have to
|
|
|
|
be specified with the B<(?>optionB<)> construct. For instance, B<(?i)> performs
|
|
|
|
a case-insensitive pattern match. More information on PCRE can be found in the
|
|
|
|
pcrepattern(3) man page (Perl Regular Expressions are explained in
|
2012-09-21 03:12:38 +00:00
|
|
|
L<http://perldoc.perl.org/perlre.html>).
|
2003-12-08 22:24:36 +00:00
|
|
|
|
2006-05-02 14:26:17 +00:00
|
|
|
=head2 Functions
|
|
|
|
|
|
|
|
The filter language has the following functions:
|
|
|
|
|
|
|
|
upper(string-field) - converts a string field to uppercase
|
|
|
|
lower(string-field) - converts a string field to lowercase
|
|
|
|
|
|
|
|
upper() and lower() are useful for performing case-insensitive string
|
|
|
|
comparisons. For example:
|
|
|
|
|
|
|
|
upper(ncp.nds_stream_name) contains "MACRO"
|
|
|
|
lower(mount.dump.hostname) == "angel"
|
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
=head2 Protocol field types
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
Each protocol field is typed. The types are:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2011-12-27 20:35:41 +00:00
|
|
|
ASN.1 object identifier
|
2003-10-15 02:13:33 +00:00
|
|
|
Boolean
|
2011-12-27 20:35:41 +00:00
|
|
|
Character string
|
|
|
|
Compiled Perl-Compatible Regular Expression (GRegex) object
|
|
|
|
Date and time
|
|
|
|
Ethernet or other MAC address
|
|
|
|
EUI64 address
|
|
|
|
Floating point (double-precision)
|
|
|
|
Floating point (single-precision)
|
|
|
|
Frame number
|
|
|
|
Globally Unique Identifier
|
2003-10-15 02:13:33 +00:00
|
|
|
IPv4 address
|
|
|
|
IPv6 address
|
|
|
|
IPX network number
|
2011-12-27 20:35:41 +00:00
|
|
|
Label
|
|
|
|
Protocol
|
|
|
|
Sequence of bytes
|
|
|
|
Signed integer, 1, 2, 3, 4, or 8 bytes
|
|
|
|
Time offset
|
|
|
|
Unsigned integer, 1, 2, 3, 4, or 8 bytes
|
2016-09-19 01:48:50 +00:00
|
|
|
1-byte ASCII character
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2016-09-19 01:48:50 +00:00
|
|
|
An integer may be expressed in decimal, octal, or hexadecimal notation,
|
|
|
|
or as a C-style character constant. The following six display filters
|
|
|
|
are equivalent:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
frame.pkt_len > 10
|
|
|
|
frame.pkt_len > 012
|
|
|
|
frame.pkt_len > 0xa
|
2016-09-19 01:48:50 +00:00
|
|
|
frame.pkt_len > '\n'
|
|
|
|
frame.pkt_len > '\xa'
|
|
|
|
frame.pkt_len > '\012'
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
Boolean values are either true or false. In a display filter expression
|
|
|
|
testing the value of a Boolean field, "true" is expressed as 1 or any
|
|
|
|
other non-zero value, and "false" is expressed as zero. For example, a
|
2004-06-03 07:37:49 +00:00
|
|
|
token-ring packet's source route field is Boolean. To find any
|
2003-10-15 02:13:33 +00:00
|
|
|
source-routed packets, a display filter would be:
|
|
|
|
|
|
|
|
tr.sr == 1
|
|
|
|
|
|
|
|
Non source-routed packets can be found with:
|
|
|
|
|
|
|
|
tr.sr == 0
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
Ethernet addresses and byte arrays are represented by hex
|
2003-10-15 02:13:33 +00:00
|
|
|
digits. The hex digits may be separated by colons, periods, or hyphens:
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
eth.dst eq ff:ff:ff:ff:ff:ff
|
|
|
|
aim.data == 0.1.0.d
|
|
|
|
fddi.src == aa-aa-aa-aa-aa-aa
|
|
|
|
echo.data == 7a
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
IPv4 addresses can be represented in either dotted decimal notation or
|
2003-10-15 02:13:33 +00:00
|
|
|
by using the hostname:
|
|
|
|
|
|
|
|
ip.dst eq www.mit.edu
|
|
|
|
ip.src == 192.168.1.1
|
|
|
|
|
|
|
|
IPv4 addresses can be compared with the same logical relations as numbers:
|
|
|
|
eq, ne, gt, ge, lt, and le. The IPv4 address is stored in host order,
|
2004-06-03 07:37:49 +00:00
|
|
|
so you do not have to worry about the endianness of an IPv4 address
|
2003-10-15 02:13:33 +00:00
|
|
|
when using it in a display filter.
|
|
|
|
|
|
|
|
Classless InterDomain Routing (CIDR) notation can be used to test if an
|
|
|
|
IPv4 address is in a certain subnet. For example, this display filter
|
|
|
|
will find all packets in the 129.111 Class-B network:
|
|
|
|
|
|
|
|
ip.addr == 129.111.0.0/16
|
|
|
|
|
|
|
|
Remember, the number after the slash represents the number of bits used
|
|
|
|
to represent the network. CIDR notation can also be used with
|
2004-06-03 07:37:49 +00:00
|
|
|
hostnames, as in this example of finding IP addresses on the same Class C
|
2003-10-15 02:13:33 +00:00
|
|
|
network as 'sneezy':
|
|
|
|
|
|
|
|
ip.addr eq sneezy/24
|
|
|
|
|
|
|
|
The CIDR notation can only be used on IP addresses or hostnames, not in
|
|
|
|
variable names. So, a display filter like "ip.src/24 == ip.dst/24" is
|
2004-06-03 07:37:49 +00:00
|
|
|
not valid (yet).
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
IPX networks are represented by unsigned 32-bit integers. Most likely
|
2004-06-03 07:37:49 +00:00
|
|
|
you will be using hexadecimal when testing IPX network values:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
ipx.src.net == 0xc0a82c00
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
Strings are enclosed in double quotes:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
http.request.method == "POST"
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
Inside double quotes, you may use a backslash to embed a double quote
|
2003-10-15 02:13:33 +00:00
|
|
|
or an arbitrary byte represented in either octal or hexadecimal.
|
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
browser.comment == "An embedded \" double-quote"
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
Use of hexadecimal to look for "HEAD":
|
|
|
|
|
|
|
|
http.request.method == "\x48EAD"
|
|
|
|
|
|
|
|
Use of octal to look for "HEAD":
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
http.request.method == "\110EAD"
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
This means that you must escape backslashes with backslashes inside
|
2004-06-03 07:37:49 +00:00
|
|
|
double quotes.
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
smb.path contains "\\\\SERVER\\SHARE"
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
looks for \\SERVER\SHARE in "smb.path".
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
=head2 The slice operator
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
You can take a slice of a field if the field is a text string or a
|
2013-06-07 17:06:27 +00:00
|
|
|
byte array.
|
2004-06-03 07:37:49 +00:00
|
|
|
For example, you can filter on
|
2003-10-15 02:13:33 +00:00
|
|
|
the vendor portion of an ethernet address (the first three bytes) like
|
|
|
|
this:
|
|
|
|
|
|
|
|
eth.src[0:3] == 00:00:83
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
Another example is:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
http.content_type[0:4] == "text"
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
You can use the slice operator on a protocol name, too.
|
|
|
|
The "frame" protocol can be useful, encompassing all the data captured
|
2006-05-31 19:12:15 +00:00
|
|
|
by B<Wireshark> or B<TShark>.
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
token[0:5] ne 0.0.0.1.1
|
2004-06-03 07:37:49 +00:00
|
|
|
llc[0] eq aa
|
2006-05-31 19:12:15 +00:00
|
|
|
frame[100-199] contains "wireshark"
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
The following syntax governs slices:
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
[i:j] i = start_offset, j = length
|
|
|
|
[i-j] i = start_offset, j = end_offset, inclusive.
|
|
|
|
[i] i = start_offset, length = 1
|
|
|
|
[:j] start_offset = 0, length = j
|
|
|
|
[i:] start_offset = i, end_offset = end_of_field
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
Offsets can be negative, in which case they indicate the
|
|
|
|
offset from the B<end> of the field. The last byte of the field is at offset
|
|
|
|
-1, the last but one byte is at offset -2, and so on.
|
|
|
|
Here's how to check the last four bytes of a frame:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
frame[-4:4] == 0.1.2.3
|
|
|
|
|
|
|
|
or
|
|
|
|
|
|
|
|
frame[-4:] == 0.1.2.3
|
|
|
|
|
2013-12-23 15:53:13 +00:00
|
|
|
A slice is always compared against either a string or a byte sequence.
|
2012-02-29 05:58:45 +00:00
|
|
|
As a special case, when the slice is only 1 byte wide, you can compare
|
|
|
|
it against a hex integer that 0xff or less (which means it fits inside
|
|
|
|
one byte). This is not allowed for byte sequences greater than one byte,
|
|
|
|
because then one would need to specify the endianness of the multi-byte
|
|
|
|
integer. Also, this is not allowed for decimal numbers, since they
|
|
|
|
would be confused with hex numbers that are already allowed as
|
|
|
|
byte strings. Neverthelss, single-byte hex integers can be convienent:
|
|
|
|
|
|
|
|
frame[4] == 0xff
|
|
|
|
|
|
|
|
Slices can be combined. You can concatenate them using the comma operator:
|
2004-06-03 07:37:49 +00:00
|
|
|
|
|
|
|
ftp[1,3-5,9:] == 01:03:04:05:09:0a:0b
|
|
|
|
|
|
|
|
This concatenates offset 1, offsets 3-5, and offset 9 to the end of the ftp
|
|
|
|
data.
|
|
|
|
|
2015-08-19 03:03:41 +00:00
|
|
|
=head2 The membership operator
|
|
|
|
|
|
|
|
A field may be checked for matches against a set of values simply with the
|
|
|
|
membership operator. For instance, you may find traffic on common HTTP/HTTPS
|
|
|
|
ports with the following filter:
|
|
|
|
|
|
|
|
tcp.port in {80 443 8080}
|
|
|
|
|
|
|
|
as opposed to the more verbose:
|
|
|
|
|
|
|
|
tcp.port == 80 or tcp.port == 443 or tcp.port == 8080
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
=head2 Type conversions
|
|
|
|
|
|
|
|
If a field is a text string or a byte array, it can be expressed in whichever
|
|
|
|
way is most convenient.
|
|
|
|
|
|
|
|
So, for instance, the following filters are equivalent:
|
|
|
|
|
|
|
|
http.request.method == "GET"
|
|
|
|
http.request.method == 47.45.54
|
|
|
|
|
|
|
|
A range can also be expressed in either way:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
frame[60:2] gt 50.51
|
|
|
|
frame[60:2] gt "PQ"
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2004-03-24 00:38:34 +00:00
|
|
|
=head2 Bit field operations
|
|
|
|
|
|
|
|
It is also possible to define tests with bit field operations. Currently the
|
|
|
|
following bit field operation is supported:
|
|
|
|
|
|
|
|
bitwise_and, & Bitwise AND
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
The bitwise AND operation allows testing to see if one or more bits are set.
|
2004-03-24 00:38:34 +00:00
|
|
|
Bitwise AND operates on integer protocol fields and slices.
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
When testing for TCP SYN packets, you can write:
|
2004-03-24 00:38:34 +00:00
|
|
|
|
|
|
|
tcp.flags & 0x02
|
|
|
|
|
2005-04-10 08:28:08 +00:00
|
|
|
That expression will match all packets that contain a "tcp.flags" field
|
|
|
|
with the 0x02 bit, i.e. the SYN bit, set.
|
|
|
|
|
2004-03-24 00:38:34 +00:00
|
|
|
Similarly, filtering for all WSP GET and extended GET methods is achieved with:
|
|
|
|
|
|
|
|
wsp.pdu_type & 0x40
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
When using slices, the bit mask must be specified as a byte string, and it must
|
2004-03-24 00:38:34 +00:00
|
|
|
have the same number of bytes as the slice itself, as in:
|
|
|
|
|
|
|
|
ip[42:2] & 40:ff
|
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
=head2 Logical expressions
|
|
|
|
|
2013-06-07 17:06:27 +00:00
|
|
|
Tests can be combined using logical expressions.
|
2010-11-09 03:20:15 +00:00
|
|
|
These too are expressible in C-like syntax or with English-like
|
2003-10-15 02:13:33 +00:00
|
|
|
abbreviations:
|
|
|
|
|
|
|
|
and, && Logical AND
|
2003-12-07 18:32:59 +00:00
|
|
|
or, || Logical OR
|
2003-10-15 02:13:33 +00:00
|
|
|
not, ! Logical NOT
|
|
|
|
|
|
|
|
Expressions can be grouped by parentheses as well. The following are
|
2003-12-07 18:32:59 +00:00
|
|
|
all valid display filter expressions:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
tcp.port == 80 and ip.src == 192.168.2.1
|
|
|
|
not llc
|
2006-05-31 19:12:15 +00:00
|
|
|
http and frame[100-199] contains "wireshark"
|
2004-06-03 07:37:49 +00:00
|
|
|
(ipx.src.net == 0xbad && ipx.src.node == 0.0.0.0.0.1) || ip
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2003-12-07 18:32:59 +00:00
|
|
|
Remember that whenever a protocol or field name occurs in an expression, the
|
|
|
|
"exists" operator is implicitly called. The "exists" operator has the highest
|
|
|
|
priority. This means that the first filter expression must be read as "show me
|
|
|
|
the packets for which tcp.port exists and equals 80, and ip.src exists and
|
|
|
|
equals 192.168.2.1". The second filter expression means "show me the packets
|
|
|
|
where not (llc exists)", or in other words "where llc does not exist" and hence
|
2004-06-03 07:37:49 +00:00
|
|
|
will match all packets that do not contain the llc protocol.
|
|
|
|
The third filter expression includes the constraint that offset 199 in the
|
|
|
|
frame exists, in other words the length of the frame is at least 200.
|
2003-12-07 18:32:59 +00:00
|
|
|
|
2003-10-15 02:13:33 +00:00
|
|
|
A special caveat must be given regarding fields that occur more than
|
|
|
|
once per packet. "ip.addr" occurs twice per IP packet, once for the
|
|
|
|
source address, and once for the destination address. Likewise,
|
2003-12-07 18:32:59 +00:00
|
|
|
"tr.rif.ring" fields can occur more than once per packet. The following
|
2003-10-15 02:13:33 +00:00
|
|
|
two expressions are not equivalent:
|
|
|
|
|
|
|
|
ip.addr ne 192.168.4.1
|
|
|
|
not ip.addr eq 192.168.4.1
|
|
|
|
|
2004-06-03 07:37:49 +00:00
|
|
|
The first filter says "show me packets where an ip.addr exists that
|
2003-10-15 02:13:33 +00:00
|
|
|
does not equal 192.168.4.1". That is, as long as one ip.addr in the
|
2004-06-03 07:37:49 +00:00
|
|
|
packet does not equal 192.168.4.1, the packet passes the display
|
|
|
|
filter. The other ip.addr could equal 192.168.4.1 and the packet would
|
|
|
|
still be displayed.
|
|
|
|
The second filter says "don't show me any packets that have an
|
|
|
|
ip.addr field equal to 192.168.4.1". If one ip.addr is 192.168.4.1,
|
|
|
|
the packet does not pass. If B<neither> ip.addr field is 192.168.4.1,
|
|
|
|
then the packet is displayed.
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2009-05-02 06:45:22 +00:00
|
|
|
It is easy to think of the 'ne' and 'eq' operators as having an implicit
|
2003-10-15 02:13:33 +00:00
|
|
|
"exists" modifier when dealing with multiply-recurring fields. "ip.addr
|
|
|
|
ne 192.168.4.1" can be thought of as "there exists an ip.addr that does
|
2004-06-03 07:37:49 +00:00
|
|
|
not equal 192.168.4.1". "not ip.addr eq 192.168.4.1" can be thought of as
|
|
|
|
"there does not exist an ip.addr equal to 192.168.4.1".
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
Be careful with multiply-recurring fields; they can be confusing.
|
|
|
|
|
|
|
|
Care must also be taken when using the display filter to remove noise
|
2004-06-03 07:37:49 +00:00
|
|
|
from the packet trace. If, for example, you want to filter out all IP
|
|
|
|
multicast packets to address 224.1.2.3, then using:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
ip.dst ne 224.1.2.3
|
|
|
|
|
|
|
|
may be too restrictive. Filtering with "ip.dst" selects only those
|
|
|
|
B<IP> packets that satisfy the rule. Any other packets, including all
|
2004-06-03 07:37:49 +00:00
|
|
|
non-IP packets, will not be displayed. To display the non-IP
|
|
|
|
packets as well, you can use one of the following two expressions:
|
2003-10-15 02:13:33 +00:00
|
|
|
|
|
|
|
not ip or ip.dst ne 224.1.2.3
|
|
|
|
not ip.addr eq 224.1.2.3
|
|
|
|
|
|
|
|
The first filter uses "not ip" to include all non-IP packets and then
|
2004-06-03 07:37:49 +00:00
|
|
|
lets "ip.dst ne 224.1.2.3" filter out the unwanted IP packets. The
|
2003-10-15 02:13:33 +00:00
|
|
|
second filter has already been explained above where filtering with
|
2010-11-09 03:20:15 +00:00
|
|
|
multiply occurring fields was discussed.
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2010-07-15 16:18:13 +00:00
|
|
|
=head1 FILTER FIELD REFERENCE
|
2003-10-15 02:13:33 +00:00
|
|
|
|
2010-07-15 16:18:13 +00:00
|
|
|
The entire list of display filters is too large to list here. You can
|
|
|
|
can find references and examples at the following locations:
|
2003-10-01 14:59:41 +00:00
|
|
|
|
2010-07-15 16:18:13 +00:00
|
|
|
=over 4
|
|
|
|
|
2013-06-07 17:06:27 +00:00
|
|
|
=item *
|
2010-07-15 16:18:13 +00:00
|
|
|
|
2014-09-17 00:08:53 +00:00
|
|
|
The online Display Filter Reference: L<https://www.wireshark.org/docs/dfref/>
|
2010-07-15 16:18:13 +00:00
|
|
|
|
2013-06-07 17:06:27 +00:00
|
|
|
=item *
|
2010-07-15 16:18:13 +00:00
|
|
|
|
|
|
|
I<Help:Supported Protocols> in Wireshark
|
|
|
|
|
2013-06-07 17:06:27 +00:00
|
|
|
=item *
|
2010-07-15 16:18:13 +00:00
|
|
|
|
|
|
|
C<tshark -G fields> on the command line
|
|
|
|
|
2013-06-07 17:06:27 +00:00
|
|
|
=item *
|
2010-07-15 16:18:13 +00:00
|
|
|
|
2015-03-10 17:46:50 +00:00
|
|
|
The Wireshark wiki: L<https://wiki.wireshark.org/DisplayFilters>
|
2010-07-15 16:18:13 +00:00
|
|
|
|
|
|
|
=back
|
2003-10-01 14:59:41 +00:00
|
|
|
|
|
|
|
=head1 NOTES
|
|
|
|
|
2006-05-31 19:12:15 +00:00
|
|
|
The B<wireshark-filters> manpage is part of the B<Wireshark> distribution.
|
|
|
|
The latest version of B<Wireshark> can be found at
|
2014-09-17 00:08:53 +00:00
|
|
|
L<https://www.wireshark.org>.
|
2003-10-01 14:59:41 +00:00
|
|
|
|
2012-09-21 03:12:38 +00:00
|
|
|
Regular expressions in the "matches" operator are provided by GRegex in GLib.
|
|
|
|
See L<http://developer.gnome.org/glib/2.32/glib-regex-syntax.html/> or L<http://www.pcre.org/> for more information.
|
2003-12-07 18:32:59 +00:00
|
|
|
|
2003-10-01 14:59:41 +00:00
|
|
|
This manpage does not describe the capture filter syntax, which is
|
2012-02-03 09:07:24 +00:00
|
|
|
different. See the manual page of pcap-filter(7) or, if that doesn't exist,
|
2015-03-10 17:46:50 +00:00
|
|
|
tcpdump(8), or, if that doesn't exist, L<https://wiki.wireshark.org/CaptureFilters>
|
2010-04-09 02:09:10 +00:00
|
|
|
for a description of capture filters.
|
2003-10-01 14:59:41 +00:00
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
2012-02-03 09:07:24 +00:00
|
|
|
wireshark(1), tshark(1), editcap(1), pcap(3), pcap-filter(7) or tcpdump(8) if it
|
|
|
|
doesn't exist.
|
2003-10-01 14:59:41 +00:00
|
|
|
|
2003-10-02 14:03:57 +00:00
|
|
|
=head1 AUTHORS
|
2003-10-01 14:59:41 +00:00
|
|
|
|
2006-05-31 19:12:15 +00:00
|
|
|
See the list of authors in the B<Wireshark> man page for a list of authors of
|
2003-10-01 14:59:41 +00:00
|
|
|
that code.
|