Christian Benvenuti wrote:
I've never managed to find a way to use the word tcp in a filter without
getting an illegal match - I know it's in the help.
The reason it does not work is that the keywords that refer to the L4
protocols (such as tcp) are supposed to be used when:
1) the u32 filter is inserted into a u32 hash table
AND
2) you jump to the above hash table from a u32 filter configured with
the "offset" option.
(unfortunately the U32 classifier is not well documented)
Ahh thanks I'll have to try some hashing tests. Last time I tried I
found that going above 512 buckets didn't work so I gave up and still
haven't looked into turning things up (I assume that's possible)
If you want to match tcp use the ip protocol match
tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match
ip dport 0xXYZ 0xFFFF match ip protocol 0x06 0xff police .....
You should invert the order of the two "match" conditions: first you make
sure it is TCP, and then you test the destination port number.
Hmm - does that really matter - I did it that way because, judging by
filter counters the first match that fails stops further matching. It
depends on what you match and your traffic patterns, but it seemed like
it would be more efficient.
This filter works in most cases, but not always: it does not take into
account the IP options. IP packets with options in the IP header will
not match.
The reason is that "ip dport" is equivalent to "offset 22" from the
beginning of the IP header.
I wonder how many packets there are like that in the wild - I don't have
much traffic to test. It's possible to make a fall through counter by
making a match and not specifying a class/flowid, though ISTR seeing a
patch recently that made me think that won't work anymore.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
