iproute2 action/policer question

iproute2 action/policer question

[Paweł Staszewski]

Hello

I ask this question here
Someone here know proper use of iproute actions/policers ?
i want to achive somethink like this

$TC qdisc del dev eth0 root

$TC qdisc add dev eth0 root handle 1: hfsc default 10


$TC class add dev eth0 parent 1:0 classid 1:2 hfsc ls m2 1kbit ul m2 
10240kbit
$TC class add dev eth0 parent 1:0 classid 1:3 hfsc ls m2 1kbit ul m2 
10240kbit
$TC class add dev eth0 parent 1:0 classid 1:10 hfsc ls m2 1kbit ul m2 
10240kbit

$TC filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip src 
10.0.0.1 flowid 1:2
$TC qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 120
#$TC filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
0/0 flowid 1:3
$TC qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 120


#$TC filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
0/0 flowid 1:3 action ipt -j MARK --set-mark 0x555 drop

$TC filter add dev eth0 parent 1: protocol ip prio 10 u32 \
  match ip src 0/0 flowid 1:3 \
  action ipt -j MARK --set-mark 1 \
  action police rate 1kbit burst 1k drop

So i want to MARK packet by use of action then pass packet to next 
action and drop if exceed 1kbit

This is only a sample but is not working

tc -s -d filter show dev eth0
filter parent 1: protocol ip pref 2 u32
filter parent 1: protocol ip pref 2 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 2 u32 fh 800::800 order 2048 key ht 
800 bkt 0 flowid 1:2  (rule hit 7913 success 7803)
  match 5ef6801c/ffffffff at 12 (success 7803 )
filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 10 u32 fh 801::800 order 2048 key ht 
801 bkt 0 flowid 1:3  (rule hit 110 success 110)
  match 00000000/00000000 at 12 (success 110 )
        action order 1: tablename: mangle  hook: NF_IP_POST_ROUTING
        target MARK xset 0x1/0xffffffff
        index 13 ref 1 bind 1 installed 407 sec used 2 sec
        Action statistics:
        Sent 42351 bytes 110 pkt (dropped 0, overlimits 0 requeues 0)
        rate 0bit 0pps backlog 0b 0p requeues 0

        action order 2:  police 0x4 rate 1000bit burst 1023b mtu 2Kb 
action drop overhead 0b
ref 1 bind 1
        Action statistics:
        Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
        rate 0bit 0pps backlog 0b 0p requeues 0

iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 19M packets, 19G bytes)
 pkts bytes target     prot opt in     out     source               
destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            
0.0.0.0/0           mark match 0x1 LOG flags 0 level 4

Chain INPUT (policy ACCEPT 19M packets, 19G bytes)
 pkts bytes target     prot opt in     out     source               
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               
destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            
0.0.0.0/0           mark match 0x1 LOG flags 0 level 4

Chain OUTPUT (policy ACCEPT 11M packets, 17G bytes)
 pkts bytes target     prot opt in     out     source               
destination

Chain POSTROUTING (policy ACCEPT 11M packets, 17G bytes)
 pkts bytes target     prot opt in     out     source               
destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            
0.0.0.0/0           mark match 0x1 LOG flags 0 level 4






Also is there someone who knows which actions from iptables can be used 
in iproute2 ?
because command like this ios not working:
tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
0/0 flowid 1:3 action ipt -j LOG
 failed to find target LOG

bad action parsing
parse_action: bad value (3:ipt)!
Illegal "action"


iptables -t mangle -A FORWARD -j LOG
is working.
lsmod
Module                  Size  Used by
ipt_LOG                 4696  3
act_ipt                 3776  1
ifb                     3444  0
act_mirred              3328  0



What is the clue of this
So i want to make filter rule on the end of some traffic management 
based on iproute2 (this filter rule will be like default class so it 
catch all unclassified traffic and LOG or MARK this traffic, and i can 
know that somewhere in my net is unclassified ip address.)
Because in normal operation if you use only iproute2 you have default 
class and you dont know what is going to this default class - this is 
hard if you use hfsc because of default class that is always active and 
matches all traffic from interface that root is attached.

Re: iproute2 action/policer question

[Jarek Poplawski]

On 09-06-2009 22:10, Paweł Staszewski wrote:
> Hello
> 
> I ask this question here
> Someone here know proper use of iproute actions/policers ?
> i want to achive somethink like this

Hi,
I'm not actions/policers expert but here are a few comments.

> 
> $TC qdisc del dev eth0 root
> 
> $TC qdisc add dev eth0 root handle 1: hfsc default 10
> 
> 
> $TC class add dev eth0 parent 1:0 classid 1:2 hfsc ls m2 1kbit ul m2 
> 10240kbit
> $TC class add dev eth0 parent 1:0 classid 1:3 hfsc ls m2 1kbit ul m2 
> 10240kbit
> $TC class add dev eth0 parent 1:0 classid 1:10 hfsc ls m2 1kbit ul m2 
> 10240kbit
> 
> $TC filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip src 
> 10.0.0.1 flowid 1:2
> $TC qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 120
> #$TC filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
> 0/0 flowid 1:3
> $TC qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 120
> 
> 
> #$TC filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
> 0/0 flowid 1:3 action ipt -j MARK --set-mark 0x555 drop
> 
> $TC filter add dev eth0 parent 1: protocol ip prio 10 u32 \
>   match ip src 0/0 flowid 1:3 \
>   action ipt -j MARK --set-mark 1 \
>   action police rate 1kbit burst 1k drop
> 
> So i want to MARK packet by use of action then pass packet to next 
> action and drop if exceed 1kbit
> 
> This is only a sample but is not working

IMHO something like this should work. (I've checked it with a bit
higher police rates/burst and htb.) I'm not sure you've properly
checked the effects, because these stats below could be simply
not updated etc.

> 
> tc -s -d filter show dev eth0
> filter parent 1: protocol ip pref 2 u32
> filter parent 1: protocol ip pref 2 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 2 u32 fh 800::800 order 2048 key ht 
> 800 bkt 0 flowid 1:2  (rule hit 7913 success 7803)
>   match 5ef6801c/ffffffff at 12 (success 7803 )
> filter parent 1: protocol ip pref 10 u32
> filter parent 1: protocol ip pref 10 u32 fh 801: ht divisor 1
> filter parent 1: protocol ip pref 10 u32 fh 801::800 order 2048 key ht 
> 801 bkt 0 flowid 1:3  (rule hit 110 success 110)
>   match 00000000/00000000 at 12 (success 110 )
>         action order 1: tablename: mangle  hook: NF_IP_POST_ROUTING
>         target MARK xset 0x1/0xffffffff
>         index 13 ref 1 bind 1 installed 407 sec used 2 sec
>         Action statistics:
>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 0 requeues 0)
>         rate 0bit 0pps backlog 0b 0p requeues 0
> 
>         action order 2:  police 0x4 rate 1000bit burst 1023b mtu 2Kb 
> action drop overhead 0b
> ref 1 bind 1
>         Action statistics:
>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
>         rate 0bit 0pps backlog 0b 0p requeues 0
> 
> iptables -L -n -v -t mangle

I don't know exactly the ipt action internals, so I could be wrong,
but it seems it marks packets as expected, but it could be done out
of the iptables chain so after these LOGs. Anyway, I managed to use it
with fw filter to classify according to the mark.

> Chain PREROUTING (policy ACCEPT 19M packets, 19G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
>     0     0 LOG        all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4
> 
> Chain INPUT (policy ACCEPT 19M packets, 19G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
>     0     0 LOG        all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4
> 
> Chain OUTPUT (policy ACCEPT 11M packets, 17G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain POSTROUTING (policy ACCEPT 11M packets, 17G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
>     0     0 LOG        all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4
> 
> 
> 
> 
> 
> 
> Also is there someone who knows which actions from iptables can be used 
> in iproute2 ?

According to iproute2/doc/actions/actions_general mangle targets
should work; and you could also try (if it doesn't work then probably
it can't be used...;-)

But... I'm neither able to configure/compile it with the current
iproute2/iptables, nor test it with distro's builds (Debian testing).
After some checking I found iproute2 needs updating, because iptables
changes API (xtables.h) virtually with every new version, so I don't
even blame the ipt author or distro maintainer.

> because command like this ios not working:
> tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
> 0/0 flowid 1:3 action ipt -j LOG
>  failed to find target LOG
> 
> bad action parsing
> parse_action: bad value (3:ipt)!
> Illegal "action"
> 
> 
> iptables -t mangle -A FORWARD -j LOG
> is working.
> lsmod
> Module                  Size  Used by
> ipt_LOG                 4696  3
> act_ipt                 3776  1
> ifb                     3444  0
> act_mirred              3328  0
> 
> 
> 
> What is the clue of this
> So i want to make filter rule on the end of some traffic management 
> based on iproute2 (this filter rule will be like default class so it 
> catch all unclassified traffic and LOG or MARK this traffic, and i can 
> know that somewhere in my net is unclassified ip address.)
> Because in normal operation if you use only iproute2 you have default 
> class and you dont know what is going to this default class - this is 
> hard if you use hfsc because of default class that is always active and 
> matches all traffic from interface that root is attached.

I guess, after studying these iproute2 docs examples you should be
able to do such tricks eg. with mirred and other actions even without
ipt. Or you could ask authors for more docs...

Cheers,
Jarek P.

PS: the tc classifier maintainer added to Cc.

Re: iproute2 action/policer question

[jamal]

On Mon, 2009-06-15 at 11:19 +0000, Jarek Poplawski wrote:

> > This is only a sample but is not working

It does seem to be working!
How did you reach conclusion it wasnt working?

> >         Action statistics:
> >         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
> >         rate 0bit 0pps backlog 0b 0p requeues 0

32 packets hit the policer - double check your parameters please to make
sure they are correct.

> According to iproute2/doc/actions/actions_general mangle targets
> should work; and you could also try (if it doesn't work then probably
> it can't be used...;-)

They should all be usable. If something crashes, there is a bug
somewhere.

> But... I'm neither able to configure/compile it with the current
> iproute2/iptables, nor test it with distro's builds (Debian testing).
> After some checking I found iproute2 needs updating, because iptables
> changes API (xtables.h) virtually with every new version, so I don't
> even blame the ipt author or distro maintainer.
> 

We are hopefully getting stable there. Anything on debian lenny
should be working with iptables 1.4.3; i expect at most "one last
change" (famous last words) to break backward compat as iptables 
moves from version 1.4.3.

> I guess, after studying these iproute2 docs examples you should be
> able to do such tricks eg. with mirred and other actions even without
> ipt. Or you could ask authors for more docs...

I have sparse time this week - but i can help with Debian Lenny which
is what my laptop runs with some variable response latency.

> PS: the tc classifier maintainer added to Cc.

Thanks as always Jarek.

cheers,
jamal

Re: iproute2 action/policer question

[Jarek Poplawski]

On Mon, Jun 15, 2009 at 09:32:08AM -0400, jamal wrote:
> On Mon, 2009-06-15 at 11:19 +0000, Jarek Poplawski wrote:
> 
> > > This is only a sample but is not working
> 
> It does seem to be working!
> How did you reach conclusion it wasnt working?
> 
> > >         Action statistics:
> > >         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
> > >         rate 0bit 0pps backlog 0b 0p requeues 0
> 
> 32 packets hit the policer - double check your parameters please to make
> sure they are correct.

Actually, I wonder if these "dropped 0" are OK here if we expect
dropping.

> 
> > According to iproute2/doc/actions/actions_general mangle targets
> > should work; and you could also try (if it doesn't work then probably
> > it can't be used...;-)
> 
> They should all be usable. If something crashes, there is a bug
> somewhere.
> 
> > But... I'm neither able to configure/compile it with the current
> > iproute2/iptables, nor test it with distro's builds (Debian testing).
> > After some checking I found iproute2 needs updating, because iptables
> > changes API (xtables.h) virtually with every new version, so I don't
> > even blame the ipt author or distro maintainer.
> > 
> 
> We are hopefully getting stable there. Anything on debian lenny
> should be working with iptables 1.4.3; i expect at most "one last
> change" (famous last words) to break backward compat as iptables 
> moves from version 1.4.3.

I've tried debian squeeze (testing) with: iptables v1.4.3.2, iproute2
-ss090324, and action ipt -j MARK doesn't work. AFAIK debian lenny
(stable) uses 1.4.2. I've also tried debian rescue probably based on
lenny (with iptables 1.4.2), and it seemed it didn't work yet (I'll
re-check this). When you have something new I'd be glad for Cc.

Thanks more than always Jamal,
Jarek P.

Re: iproute2 action/policer question

[Paweł Staszewski]

Jarek Poplawski pisze:
> On Mon, Jun 15, 2009 at 09:32:08AM -0400, jamal wrote:
>   
>> On Mon, 2009-06-15 at 11:19 +0000, Jarek Poplawski wrote:
>>
>>     
>>>> This is only a sample but is not working
>>>>         
>> It does seem to be working!
>> How did you reach conclusion it wasnt working?
>>
>>     
>>>>         Action statistics:
>>>>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
>>>>         rate 0bit 0pps backlog 0b 0p requeues 0
>>>>         
>> 32 packets hit the policer - double check your parameters please to make
>> sure they are correct.
>>     
>
>   
Yes. packets hits policer but second action dont drop packets.

Second is that in policer there is action to "-j MARK" mark packet but 
where i can catch this mark ? in iptables mangle i make some rules to 
match mark and make LOG target like this:
but iptables rules catch nothing.

Chain PREROUTING (policy ACCEPT 19M packets, 19G bytes)
 pkts bytes target     prot opt in     out     source               
 destination
     0     0 LOG        all  --  *      *       0.0.0.0/0            
 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4

Chain POSTROUTING (policy ACCEPT 11M packets, 17G bytes)
  pkts bytes target     prot opt in     out     source               
 destination
     0     0 LOG        all  --  *      *       0.0.0.0/0            
 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4


version of tools:
iptables -V
iptables v1.4.2
tc -V
tc utility, iproute2-ss090324



> Actually, I wonder if these "dropped 0" are OK here if we expect
> dropping.
>
>   
>>> According to iproute2/doc/actions/actions_general mangle targets
>>> should work; and you could also try (if it doesn't work then probably
>>> it can't be used...;-)
>>>       
>> They should all be usable. If something crashes, there is a bug
>> somewhere.
>>
>>     
>>> But... I'm neither able to configure/compile it with the current
>>> iproute2/iptables, nor test it with distro's builds (Debian testing).
>>> After some checking I found iproute2 needs updating, because iptables
>>> changes API (xtables.h) virtually with every new version, so I don't
>>> even blame the ipt author or distro maintainer.
>>>
>>>       
>> We are hopefully getting stable there. Anything on debian lenny
>> should be working with iptables 1.4.3; i expect at most "one last
>> change" (famous last words) to break backward compat as iptables 
>> moves from version 1.4.3.
>>     
>
> I've tried debian squeeze (testing) with: iptables v1.4.3.2, iproute2
> -ss090324, and action ipt -j MARK doesn't work. AFAIK debian lenny
> (stable) uses 1.4.2. I've also tried debian rescue probably based on
> lenny (with iptables 1.4.2), and it seemed it didn't work yet (I'll
> re-check this). When you have something new I'd be glad for Cc.
>
> Thanks more than always Jamal,
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   

Re: iproute2 action/policer question

[Paweł Staszewski]

Jarek Poplawski pisze:
> On 09-06-2009 22:10, Paweł Staszewski wrote:
>   
>> Hello
>>
>> I ask this question here
>> Someone here know proper use of iproute actions/policers ?
>> i want to achive somethink like this
>>     
>
> Hi,
> I'm not actions/policers expert but here are a few comments.
>
>   
>> $TC qdisc del dev eth0 root
>>
>> $TC qdisc add dev eth0 root handle 1: hfsc default 10
>>
>>
>> $TC class add dev eth0 parent 1:0 classid 1:2 hfsc ls m2 1kbit ul m2 
>> 10240kbit
>> $TC class add dev eth0 parent 1:0 classid 1:3 hfsc ls m2 1kbit ul m2 
>> 10240kbit
>> $TC class add dev eth0 parent 1:0 classid 1:10 hfsc ls m2 1kbit ul m2 
>> 10240kbit
>>
>> $TC filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip src 
>> 10.0.0.1 flowid 1:2
>> $TC qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 120
>> #$TC filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
>> 0/0 flowid 1:3
>> $TC qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 120
>>
>>
>> #$TC filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
>> 0/0 flowid 1:3 action ipt -j MARK --set-mark 0x555 drop
>>
>> $TC filter add dev eth0 parent 1: protocol ip prio 10 u32 \
>>   match ip src 0/0 flowid 1:3 \
>>   action ipt -j MARK --set-mark 1 \
>>   action police rate 1kbit burst 1k drop
>>
>> So i want to MARK packet by use of action then pass packet to next 
>> action and drop if exceed 1kbit
>>
>> This is only a sample but is not working
>>     
>
> IMHO something like this should work. (I've checked it with a bit
> higher police rates/burst and htb.) I'm not sure you've properly
> checked the effects, because these stats below could be simply
> not updated etc.
>
>   
>> tc -s -d filter show dev eth0
>> filter parent 1: protocol ip pref 2 u32
>> filter parent 1: protocol ip pref 2 u32 fh 800: ht divisor 1
>> filter parent 1: protocol ip pref 2 u32 fh 800::800 order 2048 key ht 
>> 800 bkt 0 flowid 1:2  (rule hit 7913 success 7803)
>>   match 5ef6801c/ffffffff at 12 (success 7803 )
>> filter parent 1: protocol ip pref 10 u32
>> filter parent 1: protocol ip pref 10 u32 fh 801: ht divisor 1
>> filter parent 1: protocol ip pref 10 u32 fh 801::800 order 2048 key ht 
>> 801 bkt 0 flowid 1:3  (rule hit 110 success 110)
>>   match 00000000/00000000 at 12 (success 110 )
>>         action order 1: tablename: mangle  hook: NF_IP_POST_ROUTING
>>         target MARK xset 0x1/0xffffffff
>>         index 13 ref 1 bind 1 installed 407 sec used 2 sec
>>         Action statistics:
>>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 0 requeues 0)
>>         rate 0bit 0pps backlog 0b 0p requeues 0
>>
>>         action order 2:  police 0x4 rate 1000bit burst 1023b mtu 2Kb 
>> action drop overhead 0b
>> ref 1 bind 1
>>         Action statistics:
>>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
>>         rate 0bit 0pps backlog 0b 0p requeues 0
>>
>> iptables -L -n -v -t mangle
>>     
>
> I don't know exactly the ipt action internals, so I could be wrong,
> but it seems it marks packets as expected, but it could be done out
> of the iptables chain so after these LOGs. Anyway, I managed to use it
> with fw filter to classify according to the mark.
>
>   
>> Chain PREROUTING (policy ACCEPT 19M packets, 19G bytes)
>>  pkts bytes target     prot opt in     out     source               
>> destination
>>     0     0 LOG        all  --  *      *       0.0.0.0/0            
>> 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4
>>
>> Chain INPUT (policy ACCEPT 19M packets, 19G bytes)
>>  pkts bytes target     prot opt in     out     source               
>> destination
>>
>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>  pkts bytes target     prot opt in     out     source               
>> destination
>>     0     0 LOG        all  --  *      *       0.0.0.0/0            
>> 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4
>>
>> Chain OUTPUT (policy ACCEPT 11M packets, 17G bytes)
>>  pkts bytes target     prot opt in     out     source               
>> destination
>>
>> Chain POSTROUTING (policy ACCEPT 11M packets, 17G bytes)
>>  pkts bytes target     prot opt in     out     source               
>> destination
>>     0     0 LOG        all  --  *      *       0.0.0.0/0            
>> 0.0.0.0/0           mark match 0x1 LOG flags 0 level 4
>>
>>
>>
>>
>>
>>
>> Also is there someone who knows which actions from iptables can be used 
>> in iproute2 ?
>>     
>
> According to iproute2/doc/actions/actions_general mangle targets
> should work; and you could also try (if it doesn't work then probably
> it can't be used...;-)
>
> But... I'm neither able to configure/compile it with the current
> iproute2/iptables, nor test it with distro's builds (Debian testing).
> After some checking I found iproute2 needs updating, because iptables
> changes API (xtables.h) virtually with every new version, so I don't
> even blame the ipt author or distro maintainer.
>
>   
>> because command like this ios not working:
>> tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 
>> 0/0 flowid 1:3 action ipt -j LOG
>>  failed to find target LOG
>>
>> bad action parsing
>> parse_action: bad value (3:ipt)!
>> Illegal "action"
>>
>>
>> iptables -t mangle -A FORWARD -j LOG
>> is working.
>> lsmod
>> Module                  Size  Used by
>> ipt_LOG                 4696  3
>> act_ipt                 3776  1
>> ifb                     3444  0
>> act_mirred              3328  0
>>
>>
>>
>> What is the clue of this
>> So i want to make filter rule on the end of some traffic management 
>> based on iproute2 (this filter rule will be like default class so it 
>> catch all unclassified traffic and LOG or MARK this traffic, and i can 
>> know that somewhere in my net is unclassified ip address.)
>> Because in normal operation if you use only iproute2 you have default 
>> class and you dont know what is going to this default class - this is 
>> hard if you use hfsc because of default class that is always active and 
>> matches all traffic from interface that root is attached.
>>     
>
> I guess, after studying these iproute2 docs examples you should be
> able to do such tricks eg. with mirred and other actions even without
> ipt. Or you could ask authors for more docs...
>
>   
Yes. i know that i can make mirred redirect action to some dummy 
inteface and then i can log on this device using iptables "LOG" target 
(and this is working for me now) but i was thinking about something 
simpler/faster and without special copying packets to dummy or ifb device.



> Cheers,
> Jarek P.
>
> PS: the tc classifier maintainer added to Cc.
>
>
>   


Regards
Paweł Staszewski

Re: iproute2 action/policer question

[Jarek Poplawski]

On Mon, Jun 15, 2009 at 06:09:57PM +0200, Paweł Staszewski wrote:
> Jarek Poplawski pisze:
>> On Mon, Jun 15, 2009 at 09:32:08AM -0400, jamal wrote:
>>   
>>> On Mon, 2009-06-15 at 11:19 +0000, Jarek Poplawski wrote:
>>>
>>>     
>>>>> This is only a sample but is not working
>>>>>         
>>> It does seem to be working!
>>> How did you reach conclusion it wasnt working?
>>>
>>>     
>>>>>         Action statistics:
>>>>>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
>>>>>         rate 0bit 0pps backlog 0b 0p requeues 0
>>>>>         
>>> 32 packets hit the policer - double check your parameters please to make
>>> sure they are correct.
>>>     
>>
>>   
> Yes. packets hits policer but second action dont drop packets.

I guess Jamal meant 'hit the policer' == 'dropped' (and 110 - 32
passed). So the question is how did you checked it's otherwise.

Jarek P.

Re: iproute2 action/policer question

[Jarek Poplawski]

On Mon, Jun 15, 2009 at 06:37:06PM +0200, Jarek Poplawski wrote:
> On Mon, Jun 15, 2009 at 06:09:57PM +0200, Paweł Staszewski wrote:
> > Jarek Poplawski pisze:
> >> On Mon, Jun 15, 2009 at 09:32:08AM -0400, jamal wrote:
> >>   
> >>> On Mon, 2009-06-15 at 11:19 +0000, Jarek Poplawski wrote:
> >>>
> >>>     
> >>>>> This is only a sample but is not working
> >>>>>         
> >>> It does seem to be working!
> >>> How did you reach conclusion it wasnt working?
> >>>
> >>>     
> >>>>>         Action statistics:
> >>>>>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
> >>>>>         rate 0bit 0pps backlog 0b 0p requeues 0
> >>>>>         
> >>> 32 packets hit the policer - double check your parameters please to make
> >>> sure they are correct.
> >>>     
> >>
> >>   
> > Yes. packets hits policer but second action dont drop packets.
> 
> I guess Jamal meant 'hit the policer' == 'dropped' (and 110 - 32
> passed). So the question is how did you checked it's otherwise.

Hmm... Not that we don't believe you, but some other (tc -s qdisc ?)
stats with this would be appreciated before checking the code.;-)

Jarek P.

Re: iproute2 action/policer question

[Paweł Staszewski]

Jarek Poplawski pisze:
> On Mon, Jun 15, 2009 at 06:37:06PM +0200, Jarek Poplawski wrote:
>   
>> On Mon, Jun 15, 2009 at 06:09:57PM +0200, Paweł Staszewski wrote:
>>     
>>> Jarek Poplawski pisze:
>>>       
>>>> On Mon, Jun 15, 2009 at 09:32:08AM -0400, jamal wrote:
>>>>   
>>>>         
>>>>> On Mon, 2009-06-15 at 11:19 +0000, Jarek Poplawski wrote:
>>>>>
>>>>>     
>>>>>           
>>>>>>> This is only a sample but is not working
>>>>>>>         
>>>>>>>               
>>>>> It does seem to be working!
>>>>> How did you reach conclusion it wasnt working?
>>>>>
>>>>>     
>>>>>           
>>>>>>>         Action statistics:
>>>>>>>         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
>>>>>>>         rate 0bit 0pps backlog 0b 0p requeues 0
>>>>>>>         
>>>>>>>               
>>>>> 32 packets hit the policer - double check your parameters please to make
>>>>> sure they are correct.
>>>>>     
>>>>>           
>>>>   
>>>>         
>>> Yes. packets hits policer but second action dont drop packets.
>>>       
>> I guess Jamal meant 'hit the policer' == 'dropped' (and 110 - 32
>> passed). So the question is how did you checked it's otherwise.
>>     
>
> Hmm... Not that we don't believe you, but some other (tc -s qdisc ?)
> stats with this would be appreciated before checking the code.;-)
>
>   

hmm...
Test that i make


ping -I 94.246.128.23 194.6.246.23 -s 900
PING 194.6.246.23 (194.6.246.23) from 94.246.128.23 : 900(928) bytes of 
data.
908 bytes from 194.6.246.23: icmp_seq=1 ttl=63 time=0.595 ms
908 bytes from 194.6.246.23: icmp_seq=8 ttl=63 time=0.451 ms
^C
--- 194.6.246.23 ping statistics ---
9 packets transmitted, 2 received, 77% packet loss, time 8046ms


tc -s -d filter show dev eth0
filter parent 1: protocol ip pref 2 u32
filter parent 1: protocol ip pref 2 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 2 u32 fh 800::800 order 2048 key ht 
800 bkt 0 flowid 1:2  (rule hit 145 success 134)
  match 5ef6801c/ffffffff at 12 (success 134 )
filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 10 u32 fh 801::800 order 2048 key ht 
801 bkt 0 flowid 1:3  (rule hit 11 success 11)
  match 00000000/00000000 at 12 (success 11 )
        action order 1: tablename: mangle  hook: NF_IP_POST_ROUTING
        target MARK xset 0x1/0xffffffff
        index 20 ref 1 bind 1 installed 15 sec used 3 sec
        Action statistics:
        Sent 10762 bytes 11 pkt (dropped 0, overlimits 0 requeues 0)
        rate 0bit 0pps backlog 0b 0p requeues 0

        action order 2:  police 0xf rate 1000bit burst 1023b mtu 2Kb 
action drop overhead 0b
ref 1 bind 1
        Action statistics:
        Sent 10762 bytes 11 pkt (dropped 0, overlimits 9 requeues 0)
        rate 0bit 0pps backlog 0b 0p requeues 0

tc -s -d qdisc show dev eth0
qdisc hfsc 1: root default 10
 Sent 32180 bytes 288 pkt (dropped 13, overlimits 77 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 2: parent 1:2 limit 127p quantum 1514b flows 127/1024
 Sent 30296 bytes 286 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 3: parent 1:3 limit 127p quantum 1514b flows 127/1024
 Sent 1884 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

in stats i see overlimits / no drops

but packets are dropped :) yes sorry for this that i write before - that 
there is no drops


But what with ipt -j MARK ?
Where i can catch this mark ?
Or i can't catch packet like this, but then for what will be this ipt 
action ?


Because if i understand correct this action works like iptables -j MARK 
in POSTROUTING mangle ?


> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   

Re: iproute2 action/policer question

[Jarek Poplawski]

On Mon, Jun 15, 2009 at 07:08:53PM +0200, Paweł Staszewski wrote:
...
> But what with ipt -j MARK ?
> Where i can catch this mark ?
> Or i can't catch packet like this, but then for what will be this ipt  
> action ?
>
>
> Because if i understand correct this action works like iptables -j MARK  
> in POSTROUTING mangle ?

As I wrote before I don't know these things enough, but it's probably
not exactly like using iptables; I guess it's after POSTROUTING if
used at egress or before PREROUTING if at ingress, and you could easily
check this in case of ingress: it should be visible by all iptables
hooks on it's way. So it's probably mostly useful on ingress, like in
doc examples. In case of egress if it's not redirected anywhere, as
I mentionned before, you could detect it e.g. with fw filter called
after ipt, but I'm not sure it's very useful here.

Jarek P.

[PATCH] Re: iproute2 action/policer question

[Jarek Poplawski]

On Mon, Jun 15, 2009 at 09:32:08AM -0400, jamal wrote:
> On Mon, 2009-06-15 at 11:19 +0000, Jarek Poplawski wrote:
> 
> > > This is only a sample but is not working
> 
> It does seem to be working!
> How did you reach conclusion it wasnt working?
> 
> > >         Action statistics:
> > >         Sent 42351 bytes 110 pkt (dropped 0, overlimits 32 requeues 0)
> > >         rate 0bit 0pps backlog 0b 0p requeues 0

Jamal, after looking into act_gact or act_nat I guess we should update
drops here likewise, unless I miss something?

Pawel, if it works for you could you send your "Tested-by"?

Thanks,
Jarek P.
------------------->
pkt_sched: Update drops stats in act_police

Action police statistics could be misleading because drops are not
shown when expected.

With feedback from: Jamal Hadi Salim <hadi@cyberus.ca>

Reported-by: =?ISO-8859-2?Q?Pawe=B3_Staszewski?= <pstaszewski@itcare.pl>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---

 net/sched/act_police.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index f8f047b..723964c 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -294,6 +294,8 @@ static int tcf_act_police(struct sk_buff *skb, struct tc_action *a,
 	if (police->tcfp_ewma_rate &&
 	    police->tcf_rate_est.bps >= police->tcfp_ewma_rate) {
 		police->tcf_qstats.overlimits++;
+		if (police->tcf_action == TC_ACT_SHOT)
+			police->tcf_qstats.drops++;
 		spin_unlock(&police->tcf_lock);
 		return police->tcf_action;
 	}
@@ -327,6 +329,8 @@ static int tcf_act_police(struct sk_buff *skb, struct tc_action *a,
 	}
 
 	police->tcf_qstats.overlimits++;
+	if (police->tcf_action == TC_ACT_SHOT)
+		police->tcf_qstats.drops++;
 	spin_unlock(&police->tcf_lock);
 	return police->tcf_action;
 }

Re: iproute2 action/policer question

[jamal]

On Mon, 2009-06-15 at 16:52 +0200, Jarek Poplawski wrote:

> I've tried debian squeeze (testing) with: iptables v1.4.3.2, iproute2
> -ss090324, and action ipt -j MARK doesn't work. AFAIK debian lenny
> (stable) uses 1.4.2. I've also tried debian rescue probably based on
> lenny (with iptables 1.4.2), and it seemed it didn't work yet (I'll
> re-check this). When you have something new I'd be glad for Cc.

I am suprised it broke again. 
Lets CC the debian iproute maintainer. 

cheers,
jamal

Re: [PATCH] Re: iproute2 action/policer question

[jamal]

On Mon, 2009-06-15 at 23:47 +0200, Jarek Poplawski wrote:

> 
> Jamal, after looking into act_gact or act_nat I guess we should update
> drops here likewise, unless I miss something?

It is ok for consistency. 
Nota bene: The drop is not really done by the policer; the policer
mainly suggests that the packet be dropped; so the original idea (which
is still valid) was some other action may decide to "undo" the drop. 

So feel free to add Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>

cheers,
jamal

[PATCH v2] Re: iproute2 action/policer question

[Jarek Poplawski]

Here is take 2 with Jamal's ack, and Pawel's name "simplified".
Pawel, if you're not OK with this feel free to send your "Reported-by"
line, and I hope David will replace it.

Thanks,
Jarek P.
-------------------> take 2
pkt_sched: Update drops stats in act_police

Action police statistics could be misleading because drops are not
shown when expected.

With feedback from: Jamal Hadi Salim <hadi@cyberus.ca>

Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
---

 net/sched/act_police.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index f8f047b..723964c 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -294,6 +294,8 @@ static int tcf_act_police(struct sk_buff *skb, struct tc_action *a,
 	if (police->tcfp_ewma_rate &&
 	    police->tcf_rate_est.bps >= police->tcfp_ewma_rate) {
 		police->tcf_qstats.overlimits++;
+		if (police->tcf_action == TC_ACT_SHOT)
+			police->tcf_qstats.drops++;
 		spin_unlock(&police->tcf_lock);
 		return police->tcf_action;
 	}
@@ -327,6 +329,8 @@ static int tcf_act_police(struct sk_buff *skb, struct tc_action *a,
 	}
 
 	police->tcf_qstats.overlimits++;
+	if (police->tcf_action == TC_ACT_SHOT)
+		police->tcf_qstats.drops++;
 	spin_unlock(&police->tcf_lock);
 	return police->tcf_action;
 }

Re: iproute2 action/policer question

[Jarek Poplawski]

On Tue, Jun 16, 2009 at 08:04:32AM -0400, jamal wrote:
> On Mon, 2009-06-15 at 16:52 +0200, Jarek Poplawski wrote:
> 
> > I've tried debian squeeze (testing) with: iptables v1.4.3.2, iproute2
> > -ss090324, and action ipt -j MARK doesn't work. AFAIK debian lenny
> > (stable) uses 1.4.2. I've also tried debian rescue probably based on
> > lenny (with iptables 1.4.2), and it seemed it didn't work yet (I'll
> > re-check this). When you have something new I'd be glad for Cc.
> 
> I am suprised it broke again. 
> Lets CC the debian iproute maintainer. 

I confirm I can't get 'action ipt -j MARK' working on debian lenny
(stable) with distro's iptables/tc. I'm not able to compile tc from
vanilla sources properly either - configure fails 3 IPT tests. (I
admit I can miss setting some (undocumented?) config variables.) So,
with or without debian, IMHO iproute2 needs some updates for iptables
1.4.2, 1.4.3, and maybe even 1.4.4 now.

Cheers,
Jarek P.

Re: iproute2 action/policer question

[Jarek Poplawski]

On Wed, Jun 17, 2009 at 06:14:58AM +0000, Jarek Poplawski wrote:
> On Tue, Jun 16, 2009 at 08:04:32AM -0400, jamal wrote:
> > On Mon, 2009-06-15 at 16:52 +0200, Jarek Poplawski wrote:
> > 
> > > I've tried debian squeeze (testing) with: iptables v1.4.3.2, iproute2
> > > -ss090324, and action ipt -j MARK doesn't work. AFAIK debian lenny
> > > (stable) uses 1.4.2. I've also tried debian rescue probably based on
> > > lenny (with iptables 1.4.2), and it seemed it didn't work yet (I'll
> > > re-check this). When you have something new I'd be glad for Cc.
> > 
> > I am suprised it broke again. 
> > Lets CC the debian iproute maintainer. 
> 
> I confirm I can't get 'action ipt -j MARK' working on debian lenny
> (stable) with distro's iptables/tc. I'm not able to compile tc from
> vanilla sources properly either - configure fails 3 IPT tests. (I
> admit I can miss setting some (undocumented?) config variables.) So,
> with or without debian, IMHO iproute2 needs some updates for iptables
> 1.4.2, 1.4.3, and maybe even 1.4.4 now.

OOPS! I _can_ configure it for 1.4.2 yet (so it's only about >= 1.4.3).

Sorry,
Jarek P.

Re: iproute2 action/policer question

[Jarek Poplawski]

On Wed, Jun 17, 2009 at 06:28:46AM +0000, Jarek Poplawski wrote:
> On Wed, Jun 17, 2009 at 06:14:58AM +0000, Jarek Poplawski wrote:
> > On Tue, Jun 16, 2009 at 08:04:32AM -0400, jamal wrote:
> > > On Mon, 2009-06-15 at 16:52 +0200, Jarek Poplawski wrote:
> > > 
> > > > I've tried debian squeeze (testing) with: iptables v1.4.3.2, iproute2
> > > > -ss090324, and action ipt -j MARK doesn't work. AFAIK debian lenny
> > > > (stable) uses 1.4.2. I've also tried debian rescue probably based on
> > > > lenny (with iptables 1.4.2), and it seemed it didn't work yet (I'll
> > > > re-check this). When you have something new I'd be glad for Cc.
> > > 
> > > I am suprised it broke again. 
> > > Lets CC the debian iproute maintainer. 
> > 
> > I confirm I can't get 'action ipt -j MARK' working on debian lenny
> > (stable) with distro's iptables/tc. I'm not able to compile tc from
> > vanilla sources properly either - configure fails 3 IPT tests. (I
> > admit I can miss setting some (undocumented?) config variables.) So,
> > with or without debian, IMHO iproute2 needs some updates for iptables
> > 1.4.2, 1.4.3, and maybe even 1.4.4 now.
> 
> OOPS! I _can_ configure it for 1.4.2 yet (so it's only about >= 1.4.3).

Btw., so 'action -j MARK' can work with iptables 1.4.2 & updated
iproute2, but I confirm Pawel's report that 'action -j LOG' doesn't
work yet.

Jarek P.

Re: iproute2 action/policer question

[Denys Fedoryschenko]

On Wednesday 17 June 2009 09:28:46 Jarek Poplawski wrote:

> >
> > I confirm I can't get 'action ipt -j MARK' working on debian lenny
> > (stable) with distro's iptables/tc. I'm not able to compile tc from
> > vanilla sources properly either - configure fails 3 IPT tests. (I
> > admit I can miss setting some (undocumented?) config variables.) So,
> > with or without debian, IMHO iproute2 needs some updates for iptables
> > 1.4.2, 1.4.3, and maybe even 1.4.4 now.
>
> OOPS! I _can_ configure it for 1.4.2 yet (so it's only about >= 1.4.3).
>
I check that, and found again many small changes in iptables, that screwed ipt 
action in iproute2.

I really think it doesn't worth to put too much efforts fixing it, with each 
new release iptables. I switch to other way of "tagging" packets, skbedit, 
and it seems it is also faster.

Re: iproute2 action/policer question

[Jarek Poplawski]

On Wed, Jun 17, 2009 at 12:01:37PM +0300, Denys Fedoryschenko wrote:
> On Wednesday 17 June 2009 09:28:46 Jarek Poplawski wrote:
> 
> > >
> > > I confirm I can't get 'action ipt -j MARK' working on debian lenny
> > > (stable) with distro's iptables/tc. I'm not able to compile tc from
> > > vanilla sources properly either - configure fails 3 IPT tests. (I
> > > admit I can miss setting some (undocumented?) config variables.) So,
> > > with or without debian, IMHO iproute2 needs some updates for iptables
> > > 1.4.2, 1.4.3, and maybe even 1.4.4 now.
> >
> > OOPS! I _can_ configure it for 1.4.2 yet (so it's only about >= 1.4.3).
> >
> I check that, and found again many small changes in iptables, that screwed ipt 
> action in iproute2.
> 
> I really think it doesn't worth to put too much efforts fixing it, with each 
> new release iptables. I switch to other way of "tagging" packets, skbedit, 
> and it seems it is also faster.

If it were only about -j MARK you're 100% right. Other targets could
be harder to replace - if they work of course ;-) Of course it's all
up to Jamal, but on the other hand I'm really confused debian stable
(or even testing) maintains such a broken state without any notice
or simply disabling it to save people's time.

Jarek P.

Re: [PATCH v2] Re: iproute2 action/policer question

[Paweł Staszewski]

Jarek Poplawski pisze:
> Here is take 2 with Jamal's ack, and Pawel's name "simplified".
> Pawel, if you're not OK with this feel free to send your "Reported-by"
> line, and I hope David will replace it.
>
>   
:) it's OK
> Thanks,
> Jarek P.
> -------------------> take 2
> pkt_sched: Update drops stats in act_police
>
> Action police statistics could be misleading because drops are not
> shown when expected.
>
> With feedback from: Jamal Hadi Salim <hadi@cyberus.ca>
>
> Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
> ---
>
>  net/sched/act_police.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/net/sched/act_police.c b/net/sched/act_police.c
> index f8f047b..723964c 100644
> --- a/net/sched/act_police.c
> +++ b/net/sched/act_police.c
> @@ -294,6 +294,8 @@ static int tcf_act_police(struct sk_buff *skb, struct tc_action *a,
>  	if (police->tcfp_ewma_rate &&
>  	    police->tcf_rate_est.bps >= police->tcfp_ewma_rate) {
>  		police->tcf_qstats.overlimits++;
> +		if (police->tcf_action == TC_ACT_SHOT)
> +			police->tcf_qstats.drops++;
>  		spin_unlock(&police->tcf_lock);
>  		return police->tcf_action;
>  	}
> @@ -327,6 +329,8 @@ static int tcf_act_police(struct sk_buff *skb, struct tc_action *a,
>  	}
>  
>  	police->tcf_qstats.overlimits++;
> +	if (police->tcf_action == TC_ACT_SHOT)
> +		police->tcf_qstats.drops++;
>  	spin_unlock(&police->tcf_lock);
>  	return police->tcf_action;
>  }
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   

Re: iproute2 action/policer question

[jamal]

On Wed, 2009-06-17 at 09:26 +0000, Jarek Poplawski wrote:
> On Wed, Jun 17, 2009 at 12:01:37PM +0300, Denys Fedoryschenko wrote:
> > On Wednesday 17 June 2009 09:28:46 Jarek Poplawski wrote:
> > 
> > > >
> > > > I confirm I can't get 'action ipt -j MARK' working on debian lenny
> > > > (stable) with distro's iptables/tc. I'm not able to compile tc from
> > > > vanilla sources properly either - configure fails 3 IPT tests. (I
> > > > admit I can miss setting some (undocumented?) config variables.) So,
> > > > with or without debian, IMHO iproute2 needs some updates for iptables
> > > > 1.4.2, 1.4.3, and maybe even 1.4.4 now.
> > >
> > > OOPS! I _can_ configure it for 1.4.2 yet (so it's only about >= 1.4.3).
> > >

Something like that.
It works fine with iptables 1.4.2 for Lenny on my laptop. 
It should work fine for the release after Lenny for 1.4.3 once
the debian maintainers pick up the latest iproute2.
For other Distros: it should work fine if they have iptables 1.4.2/3.
iptables 1.4.4 is not mainstream; i need to add a new test to detect
it once it is mainstream (actually i could do it before it becomes
mainstream and still make it backwards compatible).
I contributed about 10 patches to iptables to try and make sure it
doesnt break again ;-> Hopefully my efforts will be rewarded
(or as the saying goes perhaps "no good deeds go unpunished");->
I have confidence the iptables people are more aware of the API
breakages now than before - so very low probability it will break
post iptables 1.4.4.
For versions lower than iptables 1.4.1 I think i will give up instead of
making it compatible all the way back there.
I use debian exclusively (and these days all my machines are lenny) so
those are the only machines i test on.

> > I check that, and found again many small changes in iptables, that screwed ipt 
> > action in iproute2.
> > 
> > I really think it doesn't worth to put too much efforts fixing it, with each 
> > new release iptables. I switch to other way of "tagging" packets, skbedit, 
> > and it seems it is also faster.
> 
> If it were only about -j MARK you're 100% right. Other targets could
> be harder to replace - if they work of course ;-) Of course it's all
> up to Jamal, but on the other hand I'm really confused debian stable
> (or even testing) maintains such a broken state without any notice
> or simply disabling it to save people's time.
> 

It should work with others as well - if it doesnt theres a bug
somewhere. I dont have time this week - but if theres a script that is
supposed to work that doesnt work, please send it to me and i will look
into it.

cheers,
jamal

Re: iproute2 action/policer question

[Andreas Henriksson]

Hello!

On Wed, Jun 17, 2009 at 09:09:54AM -0400, jamal wrote:
[...]
> It works fine with iptables 1.4.2 for Lenny on my laptop. 
> It should work fine for the release after Lenny for 1.4.3 once
> the debian maintainers pick up the latest iproute2.

Do you mean the yet unreleased version?
The latest release, v2.6.29-1, is available in both Sid (unstable) and
Squeeze (testing) already and apparently people are having problems
with it....

[..]
> I have confidence the iptables people are more aware of the API
> breakages now than before - so very low probability it will break
> post iptables 1.4.4.
[..]

Proper .so versioning would be nice.

-- 
Andreas Henriksson
(...who only have sporadic internet access at the moment.)

Re: iproute2 action/policer question

[Jarek Poplawski]

On Wed, Jun 17, 2009 at 09:09:54AM -0400, jamal wrote:
> On Wed, 2009-06-17 at 09:26 +0000, Jarek Poplawski wrote:
> > On Wed, Jun 17, 2009 at 12:01:37PM +0300, Denys Fedoryschenko wrote:
> > > On Wednesday 17 June 2009 09:28:46 Jarek Poplawski wrote:
> > > 
> > > > >
> > > > > I confirm I can't get 'action ipt -j MARK' working on debian lenny
> > > > > (stable) with distro's iptables/tc. I'm not able to compile tc from
> > > > > vanilla sources properly either - configure fails 3 IPT tests. (I
> > > > > admit I can miss setting some (undocumented?) config variables.) So,
> > > > > with or without debian, IMHO iproute2 needs some updates for iptables
> > > > > 1.4.2, 1.4.3, and maybe even 1.4.4 now.
> > > >
> > > > OOPS! I _can_ configure it for 1.4.2 yet (so it's only about >= 1.4.3).
> > > >
> 
> Something like that.
> It works fine with iptables 1.4.2 for Lenny on my laptop. 

You mean Lenny with not Lenny's iproute2, I guess. Does 'works fine'
include 'action ipt -j LOG'? Anyway, let's say you're right here, and
it's "Lenny's" problem.

> It should work fine for the release after Lenny for 1.4.3 once
> the debian maintainers pick up the latest iproute2.

Why do you think so? I've tried it with current (git) iproute2 and
iptables 1.4.3.2 (Debian include files are eq. to vanilla), and here
is the configure output:

TC schedulers
 ATM    no
 IPT    /tmp/ipttest.c:6: error: variable 'afinfo' has initializer but incomplete type
/tmp/ipttest.c:7: error: unknown field 'libprefix' specified in initializer
/tmp/ipttest.c:7: warning: excess elements in struct initializer
/tmp/ipttest.c:7: warning: (near initialization for 'afinfo')
/tmp/ipttest.c:10: warning: 'enum exittype' declared inside parameter list
/tmp/ipttest.c:10: warning: its scope is only this definition or declaration, which is probably not what you wa
/tmp/ipttest.c:10: error: parameter 1 ('status') has incomplete type
failed test 2
In file included from /tmp/ipttest.c:2:
/home/info/src/git/iproute2/include/xt-internal.h:36: error: redefinition of 'struct xtables_rule_match'
/home/info/src/git/iproute2/include/xt-internal.h:50: error: conflicting types for 'xtables_insmod'
/usr/local/include/xtables.h:215: error: previous declaration of 'xtables_insmod' was here
/tmp/ipttest.c:11: warning: 'enum exittype' declared inside parameter list
/tmp/ipttest.c:11: warning: its scope is only this definition or declaration, which is probably not what you wa
/tmp/ipttest.c:11: error: parameter 1 ('status') has incomplete type
failed test 3 using iptables

After this I get tc compiled, but it gives misleading error messages
later (just like distro's tc).
 
> For other Distros: it should work fine if they have iptables 1.4.2/3.

The latest official version 1.4.3.2 (until today) doesn't work fine
for Debian & me (maybe we're special...).

> iptables 1.4.4 is not mainstream; i need to add a new test to detect
> it once it is mainstream (actually i could do it before it becomes
> mainstream and still make it backwards compatible).
> I contributed about 10 patches to iptables to try and make sure it
> doesnt break again ;-> Hopefully my efforts will be rewarded
> (or as the saying goes perhaps "no good deeds go unpunished");->
> I have confidence the iptables people are more aware of the API
> breakages now than before - so very low probability it will break
> post iptables 1.4.4.

I don't understand why you're defending those ugly destroyers of your
outstanding work?! (Did they threaten you? Don't worry - they're far
away in Australia... ;-)

> For versions lower than iptables 1.4.1 I think i will give up instead of
> making it compatible all the way back there.
> I use debian exclusively (and these days all my machines are lenny) so
> those are the only machines i test on.

As a matter of fact, after I couldn't even check Pawel's simple
examples neither on debian testing nor stable I was very near of
looking for another the distro...

> 
> > > I check that, and found again many small changes in iptables, that screwed ipt 
> > > action in iproute2.
> > > 
> > > I really think it doesn't worth to put too much efforts fixing it, with each 
> > > new release iptables. I switch to other way of "tagging" packets, skbedit, 
> > > and it seems it is also faster.
> > 
> > If it were only about -j MARK you're 100% right. Other targets could
> > be harder to replace - if they work of course ;-) Of course it's all
> > up to Jamal, but on the other hand I'm really confused debian stable
> > (or even testing) maintains such a broken state without any notice
> > or simply disabling it to save people's time.
> > 
> 
> It should work with others as well - if it doesnt theres a bug
> somewhere. I dont have time this week - but if theres a script that is
> supposed to work that doesnt work, please send it to me and i will look
> into it.

Just similarly to Pawel:
tc qdisc add dev lo root handle 1: htb
tc filter add dev lo parent 1: proto ip pref 5 u32 match u32 0 0 action ipt -j LOG

Cheers,
Jarek P.

Re: [PATCH v2] Re: iproute2 action/policer question

[David Miller]

From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 16 Jun 2009 20:33:55 +0200

> pkt_sched: Update drops stats in act_police
> 
> Action police statistics could be misleading because drops are not
> shown when expected.
> 
> With feedback from: Jamal Hadi Salim <hadi@cyberus.ca>
> 
> Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>

Applied, thanks!

Re: iproute2 action/policer question

[jamal]

On Wed, 2009-06-17 at 21:43 +0200, Jarek Poplawski wrote:

> You mean Lenny with not Lenny's iproute2, I guess. Does 'works fine'
> include 'action ipt -j LOG'? Anyway, let's say you're right here, and
> it's "Lenny's" problem.

I havent tried ipt LOG; Lenny cannot be updated anymore AFAIK; Andreas
may be able to give you a better answer on their strict process.

> Why do you think so? I've tried it with current (git) iproute2 and
> iptables 1.4.3.2 (Debian include files are eq. to vanilla), and here
> is the configure output:

I can almost bet you that you are linking to the wrong iptables library.
Did you install the new iptables yourself? Lenny certainly doesnt run
iptables 1.4.3.2. Note:
It is not just the headers - you need to point to the right lib. It is
a big mess.

> 
> After this I get tc compiled, but it gives misleading error messages
> later (just like distro's tc).

Refer to above.

> > For other Distros: it should work fine if they have iptables 1.4.2/3.
> 
> The latest official version 1.4.3.2 (until today) doesn't work fine
> for Debian & me (maybe we're special...).
> 

Are you running something other than lenny?
 dogo:~# iptables -V
iptables v1.4.2

> I don't understand why you're defending those ugly destroyers of your
> outstanding work?! (Did they threaten you? Don't worry - they're far
> away in Australia... ;-)
> 

Well, I have seen genuine effort to try and fix things ;->

> Just similarly to Pawel:
> tc qdisc add dev lo root handle 1: htb
> tc filter add dev lo parent 1: proto ip pref 5 u32 match u32 0 0 action ipt -j LOG

Thanks.
I will make time and chase this.

cheers,
jamal

Re: iproute2 action/policer question

[Jarek Poplawski]

On Thu, Jun 18, 2009 at 09:19:41AM -0400, jamal wrote:
> On Wed, 2009-06-17 at 21:43 +0200, Jarek Poplawski wrote:
> 
> > You mean Lenny with not Lenny's iproute2, I guess. Does 'works fine'
> > include 'action ipt -j LOG'? Anyway, let's say you're right here, and
> > it's "Lenny's" problem.
> 
> I havent tried ipt LOG; Lenny cannot be updated anymore AFAIK; Andreas
> may be able to give you a better answer on their strict process.

I think I understand this strict process; I don't understand why with
this strict process there is buggy software maintained without any
notice (if it wasn't spotted before going stable, which is hard to
believe).

> 
> > Why do you think so? I've tried it with current (git) iproute2 and
> > iptables 1.4.3.2 (Debian include files are eq. to vanilla), and here
> > is the configure output:
> 
> I can almost bet you that you are linking to the wrong iptables library.
> Did you install the new iptables yourself? Lenny certainly doesnt run
> iptables 1.4.3.2. Note:
> It is not just the headers - you need to point to the right lib. It is
> a big mess.

You mentioned: 
> > It should work fine for the release after Lenny for 1.4.3 once
> > the debian maintainers pick up the latest iproute2.

...and I use this release after Lenny named Squeeze (or Testing),
with iptables 1.4.3.2, plus fresh iproute2 from git. (I guess, btw.
this is a process used by many admins.) OK, I'd gladly point to
the right lib, but where is it described? And why similar process
on Lenny with 1.4.2 and git iproute2 doesn't need such steps. So,
again: maybe it works, but if I didn't manage, Debian didn't manage,
and even Denys (who, AFAICR, can compile even Gentoo! ;-) mentioned
he gave up ipt - then it looks like at least a bit too complex...

> > 
> > After this I get tc compiled, but it gives misleading error messages
> > later (just like distro's tc).
> 
> Refer to above.
> 
> > > For other Distros: it should work fine if they have iptables 1.4.2/3.
> > 
> > The latest official version 1.4.3.2 (until today) doesn't work fine
> > for Debian & me (maybe we're special...).
> > 
> 
> Are you running something other than lenny?
>  dogo:~# iptables -V
> iptables v1.4.2

Yes, I mentionned it at the beginning:
> But... I'm neither able to configure/compile it with the current
> iproute2/iptables, nor test it with distro's builds (Debian testing).

info@ami:~$ iptables -V
iptables v1.4.3.2

> > I don't understand why you're defending those ugly destroyers of your
> > outstanding work?! (Did they threaten you? Don't worry - they're far
> > away in Australia... ;-)
> > 
> 
> Well, I have seen genuine effort to try and fix things ;->
> 
> > Just similarly to Pawel:
> > tc qdisc add dev lo root handle 1: htb
> > tc filter add dev lo parent 1: proto ip pref 5 u32 match u32 0 0 action ipt -j LOG
> 
> Thanks.
> I will make time and chase this.

I wish you that nobody dare brake it again!

Cheers,
Jarek P.