From mboxrd@z Thu Jan 1 00:00:00 1970 From: Emmett Culley Date: Wed, 21 Nov 2007 21:57:06 +0000 Subject: Re: [LARTC] Problem deleting tc rules Message-Id: <4744A9B2.8070603@webengineer.com> List-Id: References: <200711201843.13299.pragma@omnikron.net> In-Reply-To: <200711201843.13299.pragma@omnikron.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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 " to the filter rule: >> >> tc filter add dev parent 1:0 protocol ip pref u32 match >> ip dst flowid 1: >> >> 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@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc