=head1 NAME

ethereal-filter - Ethereal filter syntax and reference

=head1 SYNOPSYS

B<ethereal> [other options]
S<[ B<-R> "filter expression" ]>

B<tethereal> [other options]
S<[ B<-R> "filter expression" ]>

=head1 DESCRIPTION

B<Ethereal> and B<Tethereal> share a powerful filter engine that help remove
the noise from a packet trace and let you see only the packets that interest
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
fields, and to check the existence of specified fields or protocols.

Filters are also used by other features such as statistics generation and
packet list colorization (the latter is only available to B<Ethereal>). This
manual page describes their syntax and provides a comprehensive reference of
filter fields.

=head1 FILTER SYNTAX

=head2 Check whether a field or protocol exists

The simplest filter allows you to check for the existence of a protocol or
field.  If you want to see all packets which contain the IPX protocol, the
filter would be "ipx".  (Without the quotation marks) To see all packets
that contain a Token-Ring RIF field, use "tr.rif".

Think of a protocol or field in a filter as implicitly having the "exists"
operator.

Note: all protocol and field names that are available in B<Ethereal> and
B<Tethereal> filters are listed in the B<FILTER PROTOCOL REFERENCE> (see
below).

=head2 Comparison operators

Fields can also be compared against values.  The comparison operators
can be expressed either through C-like symbols, or through English-like
abbreviations:

    eq, ==    Equal
    ne, !=    Not equal
    gt, >     Greater than
    lt, <     Less Than
    ge, >=    Greater than or Equal to
    le, <=    Less than or Equal to

=head2 Search and match operators

Additional operators exist expressed only in English, not punctuation:

	contains  Does the protocol, byte-string, or text string contain a value
	matches   Does the text string match the given Perl regular expression

The "contains" operator allows a filter to search for any sequence of
characters that may occur in a protocol or field.  The "contains"
operator is only implemented for protocols (in which case the sequence
of characters is searched for in the data for that protocol), text
fields, and raw data fields.  For example, to search for a given HTTP
URL in a capture, the following filter can be used:

	http contains "http://www.ethereal.com"

The "matches" operator allows a filter to apply to a specified
Perl-compatible regular expression (PCRE).  The "matches" operator is only
implemented for protocols, and also for protocol fields with a text string
representation.  For example, to search for a given WAP WSP User-Agent,
one can write:

	wsp.user_agent matches "(?i)cldc"

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
B<http://www.perldoc.com/perl5.8.0/pod/perlre.html>).

Note: the "matches" operator is only available if B<Ethereal> or B<Tethereal>
have been compiled with the PCRE library. This can be checked by running:

	ethereal -v
	tethereal -v

or selecting the "About Ethereal" item from the "Help" menu in B<Ethereal>.

=head2 Protocol field types

Furthermore, each protocol field is typed. The types are:

    Unsigned integer (either 8-bit, 16-bit, 24-bit, or 32-bit)
    Signed integer (either 8-bit, 16-bit, 24-bit, or 32-bit)
    Boolean
    Ethernet address (6 bytes)
    Byte string (n-number of bytes)
    IPv4 address
    IPv6 address
    IPX network number
    Text string
    Double-precision floating point number

An integer may be expressed in decimal, octal, or hexadecimal notation. 
The following three display filters are equivalent:

    frame.pkt_len > 10
    frame.pkt_len > 012
    frame.pkt_len > 0xa

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
token-ring packet's source route field is boolean.  To find any
source-routed packets, a display filter would be:

    tr.sr == 1

Non source-routed packets can be found with:

    tr.sr == 0

Ethernet addresses, as well as a string of bytes, are represented in hex
digits.  The hex digits may be separated by colons, periods, or hyphens:

    fddi.dst eq ff:ff:ff:ff:ff:ff
    ipx.srcnode == 0.0.0.0.0.1
    eth.src == aa-aa-aa-aa-aa-aa

If a string of bytes contains only one byte, then it is represented as
an unsigned integer.  That is, if you are testing for hex value 'ff' in
a one-byte byte-string, you must compare it agains '0xff' and not 'ff'. 

IPv4 addresses can be represented in either dotted decimal notation, or
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,
so you do not have to worry about how the endianness of an IPv4 address
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
hostnames, in this example of finding IP addresses on the same Class C
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
not valid.  (yet)

IPX networks are represented by unsigned 32-bit integers.  Most likely
you will be using hexadecimal when testing for IPX network values:

    ipx.srcnet == 0xc0a82c00

Strings are enclosed in double-quotes:

    http.request.method == "POST"

Inside double quotes, you may use the backslash to embed a double-quote,
or an arbitrary byte represented in either octal or hexadecimal.

    browser.comment == "An embedded \" double-quote"

Use of hexadecimal to look for "HEAD":

    http.request.method == "\x48EAD"

Use of octal to look for "HEAD":

    http.request.method == "\x110EAD"

This means that you must escape backslashes with backslashes inside
double quotes:

    smb.path contains "\\\\SERVER\\SHARE"

to look for \\SERVER\SHARE in "smb.path".

=head2 The slice operator

A slice operator also exists.  You can check the substring
(byte-string) of any protocol or field.  For example, you can filter on
the vendor portion of an ethernet address (the first three bytes) like
this:

    eth.src[0:3] == 00:00:83

If the length of your byte-slice is only one byte, then it is still
represented in hex, but without the preceding "0x": 

    llc[3] == aa

You can use the slice operator on a protocol name, too.  And
remember, the "frame" protocol encompasses the entire packet, allowing
you to look at the nth byte of a packet regardless of its frame type
(Ethernet, token-ring, etc.).

    token[0:5] ne 0.0.0.1.1
    ipx[0:2] == ff:ff
    llc[3:1] eq 0xaa

The following syntax governs slices:

	[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

Offsets and lengths can be negative, in which case they indicate the
offset from the B<end> of the field.  Here's how to check the last 4
bytes of a frame:

    frame[-4:4] == 0.1.2.3

or

    frame[-4:] == 0.1.2.3

You can create complex concatenations of slices using the comma operator:

	field[1,3-5,9:] == 01:03:04:05:09:0a:0b

=head2 Logical expressions

All the above tests can be combined together with logical expressions. 
These too are expressable in C-like syntax or with English-like
abbreviations:

    and, &&   Logical AND
    or,  ||   Logical OR
    not, !    Logical NOT

Expressions can be grouped by parentheses as well.  The following are
all valid display filter expressions:

    tcp.port == 80 and ip.src == 192.168.2.1
    not llc
    (ipx.srcnet == 0xbad && ipx.srnode == 0.0.0.0.0.1) || ip
    tr.dst[0:3] == 0.6.29 xor tr.src[0:3] == 0.6.29

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
will match all packets that do not convey the llc protocol.

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,
"tr.rif.ring" fields can occur more than once per packet.  The following
two expressions are not equivalent:

        ip.addr ne 192.168.4.1
    not ip.addr eq 192.168.4.1

The first filter says "show me IP packets where an ip.addr exists that
does not equal 192.168.4.1".  That is, as long as one ip.addr in the
packet does not equal 192.168.44.1, the packet passes the display
filter.  The second filter "don't show me any packets that have at least
one 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 fields is 192.168.4.1,
then the packet passes.

It is easy to think of the 'ne' and 'eq' operators as having an implict
"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
not equal 192.168.4.1".

Be careful with multiply-recurring fields; they can be confusing.

Care must also be taken when using the display filter to remove noise
from the packet trace. If you want to e.g. filter out all IP multicast
packets to address 224.1.2.3, then using:

    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
non-IP packets, will not be displayed. For displaying also the non-IP
packets, you can use one of the following two expressions:

    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
lets "ip.dst ne 224.1.2.3" to filter out the unwanted IP packets. The
second filter has already been explained above where filtering with
multiply occuring fields was discussed.

=head1 FILTER PROTOCOL REFERENCE

Each entry below provides an abbreviated protocol or field name.  Every
one of these fields can be used as a display filter.  The type of the
field is also given.

=insert_dfilter_table

=head1 NOTES

The B<ethereal-filters> manpage is part of the B<Ethereal> distribution.
The latest version of B<Ethereal> can be found at
B<http://www.ethereal.com>.

Regular expressions in the "matches" operator are provided with B<libpcre>,
the Perl-Compatible Regular Expressions library, see B<http://www.pcre.org/>.

This manpage does not describe the capture filter syntax, which is
different. See the tcpdump(8) manpage for a description of capture
filters. Microsoft Windows versions use WinPcap from
B<http://winpcap.polito.it/> for which the capture filter syntax is described
in B<http://winpcap.polito.it/docs/man/html/group__language.html>.

=head1 SEE ALSO

I<ethereal(1)>, I<tethereal(1)>, I<editcap(1)>, I<tcpdump(8)>, I<pcap(3)>

=head1 AUTHORS

See the list of authors in the B<Ethereal> man page for a list of authors of
that code.