Szymon Stefanek wrote:
On Wednesday 21 November 2007 00:47, Emmett Culley wrote:
Szymon Stefanek wrote:
I have an imq device with dynamically attacched classes/qdiscs/filters.
There is a hashing filter that
[...]
So finally, can I programmatically remove a filter without knowing
exactly its handle ? How ? Is there another way to match filters ? Maybe
on flowid... ? Add/remove by using direct syscalls ?
I resolved this by adding "pref <LASTIPOCTETHEX>" to the filter rule:
tc filter add dev <iface> parent 1:0 protocol ip pref <user_id> u32 match
ip dst <user_ip> flowid 1:<user_id (HEX)>
replacing "add" with "del" to remove filter.
In my case I used the last two octets to create a user_id value as I am
serving DHCP to subnet 172.16.128.0/17
Note that the pref value has to be in base 10.
Hum. I have tried this.
Or better, my problem manifests when there are collisions of filters
inside a single hashtable bucket. Since the ht is hashing by last octet
then a single bucket can contain 2^24 ip addresses (the remaining octets).
I have then tried using (ipaddress >> 8) as preference value.
Here comes the first problem: priority values seem to be limited to 16 bits.
That is, if you add something with priority 0xaffff you'll end up with
real priority 0xffff which will collide with 0xbffff, for example.
The second problem is that if I use priority then I get a very different
filter layout. For each different priority used two additional filter
lines are printed by "tc filter show"...
The difference is between:
filter parent 1: protocol ip pref 5 u32
filter parent 1: protocol ip pref 5 u32 fh 2: ht divisor 256
filter parent 1: protocol ip pref 5 u32 fh 2:1:800 order 2048 key ht 2 bkt 1
flowid 1:4098 (rule hit 0 success 0)
match 0a050001/ffffffff at 16 (success 0 )
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt
0 link 2: (rule hit 0 success 0)
match 00000000/00000000 at 12 (success 0 )
hash mask 000000ff at 16
where priority wasn't used (and it's working) and
filter parent 1: protocol ip pref 5 u32
filter parent 1: protocol ip pref 5 u32 fh 2: ht divisor 256
filter parent 1: protocol ip pref 5 u32 fh 2:1:800 order 2048 key ht 2 bkt 1
flowid 1:4098 (rule hit 0 success 0)
match 0a050001/ffffffff at 16 (success 0 )
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt
0 link 2: (rule hit 0 success 0)
match 00000000/00000000 at 12 (success 0 )
hash mask 000000ff at 16
filter parent 1: protocol ip pref 7 u32
filter parent 1: protocol ip pref 7 u32 fh 801: ht divisor 1
where a different priority was used.
Hm? Looks ugly.
Now, I'm not a tc expert but the output suggests that a complexier filter
hierarchy is created in this case and an additional "fh 801:" jumps
out from nowhere. In both cases the filter I've just added is the third line
of the listing: in the second listing it STILL has pref of 5! (????)
Since I tend to not trust stuff that I don't understand
at the moment I've choosen the very-dirty-but-at-least-undestandable solution
of using some grep & sed to get back the filter handle.
To add:
tc filter add dev @IMQDEV@ protocol ip parent 1:0 prio 5 u32 ht
2:@LASTIPOCTETHEX@: match ip src @IPADDRESS@ flowid 1:@TCCLASSID@
To remove:
tc filter del dev @IMQDEV@ parent 1:0 handle
$(
tc -s filter show dev @IMQDEV@ | grep 'flowid 1:@TCCLASSID@' |
sed -e 's/filter[A-Za-z0-9: ]*fh//' | sed -e 's/order.*//'
)
prio 5 u32
This forces me to spawn several children through a shell, is strongly
dependant on tc output (that might change in a future version) and makes batch
processing impossible...but at least it works and *maybe* I'll undestand it
in one year from now :D
...but if somebody comed out with a nicer solution I'd happily use it...
Here's what I show (for one connection):
[root@lab1 ~]# tc filter show dev eth0
filter parent 1: protocol ip pref 65004 u32
filter parent 1: protocol ip pref 65004 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 65004 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:fdec
match ac13fef6/ffffffff at 16
[
This is with the last two octets (254.246 in this case).
I understand from the docs and much googling that the pref parameter is only to give priority within a class, but in this case each user has it's own qdisc and class rule. And it seems to be working.
I'd be happy to send you the entire configuration...
Regards,
Emmett
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
