Update the man page for the new display filter code.

svn path=/trunk/; revision=3113
This commit is contained in:
Guy Harris 2001-03-06 20:36:42 +00:00
parent 30eb87d558
commit 3e73883db0
1 changed files with 23 additions and 41 deletions

View File

@ -301,53 +301,24 @@ 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 read filter.
Classless InterDomain Routing (CIDR) notation can be used to test if an
IPv4 address is in a certain subnet. For example, this read 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 read 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
A substring operator also exists. You can check the substring
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
Or more simply, since the number of bytes is inherent in the byte-string
you provide, you can provide just the offset. The previous example can
be stated like this:
If the length of your byte-slice is only one byte, then it is still
represented in hex, but without the preceding "0x":
eth.src[0] == 00:00:83
llc[3] == aa
In fact, the only time you need to explicitly provide a length is when
you don't provide a byte-string, and are comparing fields against
fields:
fddi.src[0:3] == fddi.dst[0:3]
If the length of your byte-string is only one byte, then it must be
represented in the same way as an unsigned 8-bit integer:
llc[3] == 0xaa
You can use the substring operator on a protocol name, too. And
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.).
@ -356,16 +327,28 @@ you to look at the nth byte of a packet regardless of its frame type
ipx[0:2] == ff:ff
llc[3:1] eq 0xaa
Offsets for byte-strings can also be negative, in which case the
negative number indicates the number of bytes from the end of the field
or protocol that you are testing. Here's how to check the last 4 bytes
of a frame:
frame[-4] == 0.1.2.3
The following syntax governs slices:
or
[i:j] i = start_offset, j = length
[i-j] i = start_offet, 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
All the above tests can be combined together with logical expressions.
These too are expressable in C-like syntax or with English-like
@ -373,7 +356,6 @@ abbreviations:
and, && Logical AND
or, || Logical OR
xor, ^^ Logical XOR
not, ! Logical NOT
Expressions can be grouped by parentheses as well. The following are