Wireshark · Ethereal-users: RE: [Ethereal-users] Colour filter problem

[Biot Olivier <Olivier.Biot@xxxxxxxxxxx>]

| -----Original Message-----
| From: el_lobo@xxxxxxxxxxxxxxx
| 
| Have just downloaded the latest version of Ethereal and installed it
| on NT4 workstation. Seems to capture and display data OK, but when I
| tried to set up some colour filters it keeps giving me the error:
| 
| 'Filter "name" did not compile correctly. Please try again. Filter
| unchanged. Unexpected end of filter string'
| and won't store the filter expression.

The name of protocols and protocol fields that are used in Ethereal filters
may change between two versions. The best way to know a field name is to
have a look at the Help -> Supported Protocols menu in Ethereal, and then
look up the protocols and fields you want to use in your color filter
expression.

| I have seen the reference to 'Unexpected end of filter string' within
| the FAQ - but it doesn't appear to apply to my problem.

As I read your mail, you don't have access to the *NIX man pages which
currently are the main documentation of Ethereal. Hence I include the start
of the ethereal-filter manpage.

Regards,

Olivier

--------------------

NAME
    ethereal-filter - Ethereal filter syntax and reference

SYNOPSYS
    ethereal [other options] [ -R "filter expression" ]

    tethereal [other options] [ -R "filter expression" ]

DESCRIPTION
    Ethereal and 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 Ethereal).
    This manual page describes their syntax and provides a comprehensive
    reference of filter fields.

FILTER SYNTAX
  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 Ethereal and
    Tethereal filters are listed in the FILTER PROTOCOL REFERENCE (see
    below).

  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

  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 (?option) construct. For instance, (?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 http://www.perldoc.com/perl5.8.0/pod/perlre.html).

    Note: the "matches" operator is only available if Ethereal or 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 Ethereal.

  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".

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

  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 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 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.