The U32 filter is the most advanced filter available in the current
implementation. It entirely based on hashing tables, which make it
robust when there are many filter rules.
In its simplest form the U32 filter is a list of records, each
consisting of two fields: a selector and an action. The selectors,
described below, are compared with the currently processed IP packet
until the first match occurs, and then the associated action is performed.
The simplest type of action would be directing the packet into defined
CBQ class.
The command line of tc filter program, used to configure the filter,
consists of three parts: filter specification, a selector and an action.
The filter specification can be defined as:
tc filter add dev IF [ protocol PROTO ]
[ (preference|priority) PRIO ]
[ parent CBQ ] |
The protocol field describes protocol that the filter will be
applied to. We will only discuss case of ip protocol. The
preference field (priority can be used alternatively)
sets the priority of currently defined filter. This is important, since
you can have several filters (lists of rules) with different priorities.
Each list will be passed in the order the rules were added, then list with
lower priority (higher preference number) will be processed. The parent
field defines the CBQ tree top (e.g. 1:0), the filter should be attached
to.
The options described above apply to all filters, not only U32.
The U32 selector contains definition of the pattern, that will be matched
to the currently processed packet. Precisely, it defines which bits are
to be matched in the packet header and nothing more, but this simple
method is very powerful. Let's take a look at the following examples,
taken directly from a pretty complex, real-world filter:
# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
match u32 00100000 00ff0000 at 0 flowid 1:10 |
For now, leave the first line alone - all these parameters describe
the filter's hash tables. Focus on the selector line, containing
match keyword. This selector will match to IP headers, whose
second byte will be 0x10 (0010). As you can guess, the 00ff number is
the match mask, telling the filter exactly which bits to match. Here
it's 0xff, so the byte will match if it's exactly 0x10. The at
keyword means that the match is to be started at specified offset (in
bytes) -- in this case it's beginning of the packet. Translating all
that to human language, the packet will match if its Type of Service
field will have `low delay' bits set. Let's analyze another rule:
# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
match u32 00000016 0000ffff at nexthdr+0 flowid 1:10 |
The nexthdr option means next header encapsulated in the IP packet,
i.e. header of upper-layer protocol. The match will also start here
at the beginning of the next header. The match should occur in the
second, 32-bit word of the header. In TCP and UDP protocols this field
contains packet's destination port. The number is given in big-endian
format, i.e. older bits first, so we simply read 0x0016 as 22 decimal,
which stands for SSH service if this was TCP. As you guess, this match
is ambiguous without a context, and we will discuss this later.
Having understood all the above, we will find the following selector
quite easy to read: match c0a80100 ffffff00 at 16. What we
got here is a three byte match at 17-th byte, counting from the IP
header start. This will match for packets with destination address
anywhere in 192.168.1/24 network. After analyzing the examples, we
can summarize what we have learned.
General selectors define the pattern, mask and offset the pattern
will be matched to the packet contents. Using the general selectors
you can match virtually any single bit in the IP (or upper layer)
header. They are more difficult to write and read, though, than
specific selectors that described below. The general selector syntax
is:
match [ u32 | u16 | u8 ] PATTERN MASK [ at OFFSET | nexthdr+OFFSET] |
One of the keywords u32, u16 or u8 specifies
length of the pattern in bits. PATTERN and MASK should follow, of length
defined by the previous keyword. The OFFSET parameter is the offset,
in bytes, to start matching. If nexthdr+ keyword is given,
the offset is relative to start of the upper layer header.
Some examples:
# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
match u8 64 0xff at 8 \
flowid 1:4 |
Packet will match to this rule, if its time to live (TTL) is 64.
TTL is the field starting just after 8-th byte of the IP header.
# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
match u8 0x10 0xff at nexthdr+13 \
protocol tcp \
flowid 1:3 |
FIXME: it has been pointed out that this syntax does not work currently.
Use this to match ACKs on packets smaller than 64 bytes:
## match acks the hard way,
## IP protocol 6,
## IP header length 0x5(32 bit words),
## IP Total length 0x34 (ACK + 12 bytes of TCP options)
## TCP ack set (bit 5, offset 33)
# tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:3 |
This rule will only match TCP packets with ACK bit set, and no further
payload. Here we can see an example of using two selectors, the final result
will be logical AND of their results. If we take a look at TCP header
diagram, we can see that the ACK bit is second older bit (0x10) in the 14-th
byte of the TCP header (at nexthdr+13). As for the second
selector, if we'd like to make our life harder, we could write match u8
0x06 0xff at 9 instead of using the specific selector protocol
tcp, because 6 is the number of TCP protocol, present in 10-th byte of
the IP header. On the other hand, in this example we couldn't use any
specific selector for the first match - simply because there's no specific
selector to match TCP ACK bits.
