forked from osmocom/wireshark
Update the man page for the new display filter code.
svn path=/trunk/; revision=3113
This commit is contained in:
parent
30eb87d558
commit
3e73883db0
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue