From: Emmett Culley <emmett@webengineer.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Problem deleting tc rules
Date: Tue, 20 Nov 2007 23:47:07 +0000 [thread overview]
Message-ID: <474371FB.60404@webengineer.com> (raw)
In-Reply-To: <200711201843.13299.pragma@omnikron.net>
Szymon Stefanek wrote:
> Hi all! :)
>
> I see that this is partially covered in the mailing list archive
> but at the moment I can't find a straight & working answer.
>
> I have an imq device with dynamically attacched classes/qdiscs/filters.
> There is a hashing filter that maps the last octet of an user's IP address
> to a class (and associated qdisc). The "empty" filter looks like this:
>
> 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 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
>
> I'm adding the hash entries dynamically, as users get attacched to the system
> (this is a dynamic PPPoE access concentrator).
>
> tc filter add dev imq0 protocol ip parent 1:0 prio 5 u32 ht
> 2:<LASTIPOCTETHEX>: match ip dst <IPADDRESS> flowid 1:<CLASSID>
>
> <IPADDRESS> is the address of the newly attacched user, <CLASSID> is
> a dynamically assigned unique identifier and <LASTIPOCTETHEX> is the
> last octet of the user's IP address.
>
> This works and I get a tc tree like this:
>
> 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
>
> Nice.
>
> If another user gets added to the same hash bucket I get something like:
>
> 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 2:1:801 order 2048 key ht 2 bkt 1
> flowid 1:4099 (rule hit 0 success 0)
> match 0a060001/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
>
>
> Now when the users go away I want to _programmatically_ remove the associated
> filter entries. This doesn't work unless I manually specify the filter handle
> (handle 2:1:801). The problem is that I actually don't know the filter
> handle since its last part is assigned automatically by tc. I would need
> to relaunch tc with the show option, capture its output and parse it...
> this is an overkill. If I try to delete handle 2:1: (just like in the add
> command) then ALL the rules with handle 2:1:* get deleted (and this is
> obviously not what I want).
>
> Trying to add filters with completly specified handle (like fh 2:1:4098)
> doesn't work unless the last part is EXACTLY what tc would set automatically
> (this is 800, 801 etc...). But since I have multiple unsynchronized processes
> that do the adding job then I don't know which handles have been already
> used and thus can't guess what which handle to add next. Synchronizing
> the processes and sharing a database would be again a very huge overkill.
>
> Trying to assign an unique filter id by using pref creates a mess since it
> adds three filters at once for every preference value. And removing doesn't
> work either with tc complaining about "No such file or directory".
>
> I have read somewhere that deleting a qdisc will also delete the filters
> attacched to it but this doesn't seem to work: the qdisc is deleted
> but the filter in the hash bucket is not.
>
> 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.
Regards,
Emmett
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2007-11-20 23:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-20 17:43 [LARTC] Problem deleting tc rules Szymon Stefanek
2007-11-20 23:47 ` Emmett Culley [this message]
2007-11-21 1:27 ` Szymon Stefanek
2007-11-21 21:57 ` Emmett Culley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=474371FB.60404@webengineer.com \
--to=emmett@webengineer.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox