LARTC - May 2005 - problem with filters - packets ''slipping'' through them when they shouldn''t

Hi!
I''m trying to shape my internet connection traffic using hsfc and
I''ve
encountered the following problem (may not be connected with hfsc).
on my lan interface I shape incoming traffic like this:

tc qdisc add root dev eth1  handle 1: hfsc default 1003
tc class add dev eth1 parent 1:0 classid 1:1003 hfsc ls rate 10kbit ul rate 
10kbit
tc class add dev eth1 parent 1: classid 1:1001 hfsc ls rate 70Mbit ul rate 
70Mbit

tc filter add dev eth1 parent 1: protocol ip prio 1 u32 \
               match ip src 192.168.0.1 \
               flowid 1:1001

tc class add dev eth1 parent 1: classid 1:1002 hfsc ls rate 1Mbit ul rate 
1Mbit
tc filter add dev eth1 parent 1: protocol ip prio 2 u32 \
               match ip dst 192.168.0.0/24 \
               flowid 1:1002

class 1001 recievs the traffic generated by the server
class 1002 gets incoming traffic from the internet 
class 1003 is the default

And that''s where my problem is - 1003 shouldn''t get any
traffic since (as I
think) the above filters should in total match everything and direct it to 
1001/2. But there are some packets that go to 1003 and if I delete it, most 
of the traffic dies (even ping 192.168.0.2 doesn''t work - whats even
more
wierd, not immediately, but after a minute or so from installing new queue)

Can anybody help me? Am I missing something in the filters? I''ve tried
doing
the same with iptables and mark in the postrouting chain and with fw filters. 
The situation was strange as well - every packet got marked either for the 
first or the second class, and in spite of this 1003 got traffic anyway...

thanks for any hints
Martin

Marcin Kałuża wrote:
> Hi!
> I''m trying to shape my internet connection traffic using hsfc and
I''ve
> encountered the following problem (may not be connected with hfsc).
> on my lan interface I shape incoming traffic like this:
> 
> tc qdisc add root dev eth1  handle 1: hfsc default 1003
> tc class add dev eth1 parent 1:0 classid 1:1003 hfsc ls rate 10kbit ul rate
> 10kbit
> tc class add dev eth1 parent 1: classid 1:1001 hfsc ls rate 70Mbit ul rate 
> 70Mbit
> 
> tc filter add dev eth1 parent 1: protocol ip prio 1 u32 \
>                match ip src 192.168.0.1 \
>                flowid 1:1001
> 
> tc class add dev eth1 parent 1: classid 1:1002 hfsc ls rate 1Mbit ul rate 
> 1Mbit
> tc filter add dev eth1 parent 1: protocol ip prio 2 u32 \
>                match ip dst 192.168.0.0/24 \
>                flowid 1:1002
> 
> class 1001 recievs the traffic generated by the server
> class 1002 gets incoming traffic from the internet 
> class 1003 is the default
> 
> And that''s where my problem is - 1003 shouldn''t get any
traffic since (as I
> think) the above filters should in total match everything and direct it to 
> 1001/2. But there are some packets that go to 1003 and if I delete it, most
> of the traffic dies (even ping 192.168.0.2 doesn''t work - whats
even more
> wierd, not immediately, but after a minute or so from installing new queue)
It''s arp traffic - your filters are catching IP it stops working when 
the cache expires. Unlike htb hfsc drops traffic it doesn''t know what
to
do with if you don''t specify a default class.
> 
> Can anybody help me? Am I missing something in the filters? I''ve
tried doing
> the same with iptables and mark in the postrouting chain and with fw
filters.
> The situation was strange as well - every packet got marked either for the 
> first or the second class, and in spite of this 1003 got traffic anyway...
If you don''t want use default you could classify with a TC filter

.... protocol arp u32 match u32 0 0 ....

Andy.

Thanks :)
I didn''t think of that :)
Martin

On Tuesday 03 May 2005 15:38, you wrote:
>
> If you don''t want use default you could classify with a TC filter
>
> .... protocol arp u32 match u32 0 0 ....
>
> Andy.