[LARTC] tc filter add ... fw returns RTNETLINK answers: Invalid

[LARTC] tc filter add ... fw returns RTNETLINK answers: Invalid

[Flemming Frandsen]

When I run this:
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw

I get:
RTNETLINK answers: Invalid argument

The traditional interpretation of that gnarly error message is that 
cls_fw is missing, but lsmod | grep cls_fw gets me:
cls_fw                  2336   4  (autoclean)

I can't remove it because it's in use, but all 4 statements that use it 
failed, so I'm really stumped.


This is what happens in begining of the traffic shaper script:

+ tc qdisc del dev eth0 root
+ tc qdisc add dev eth0 root handle 1: htb default 0x42
+ tc class add dev eth0 parent 1: classid 1:1 htb rate 700kbit burst 6k
+ tc class add dev eth0 parent 1:1 classid 1:42 htb rate 600kbit burst 
15k prio 0
+ tc qdisc add dev eth0 parent 1:42 handle 42: sfq perturb 20
+ tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw
RTNETLINK answers: Invalid argument
+ iptables -t mangle -N to-dsl

Any clues?

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers: Invalid

[Muthukumar S]

On 1/10/06, Flemming Frandsen <ff@nrvissing.net> wrote:
> When I run this:
> tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw
>
> I get:
> RTNETLINK answers: Invalid argument

You are missing the flowid. For example
tc filter add dec eth0 parent 1: protocol ip prio 1 handle 1 fw flowid 1:42


>
> The traditional interpretation of that gnarly error message is that
> cls_fw is missing, but lsmod | grep cls_fw gets me:
> cls_fw                  2336   4  (autoclean)
>
> I can't remove it because it's in use, but all 4 statements that use it
> failed, so I'm really stumped.
>
>
> This is what happens in begining of the traffic shaper script:
>
> + tc qdisc del dev eth0 root
> + tc qdisc add dev eth0 root handle 1: htb default 0x42
> + tc class add dev eth0 parent 1: classid 1:1 htb rate 700kbit burst 6k
> + tc class add dev eth0 parent 1:1 classid 1:42 htb rate 600kbit burst
> 15k prio 0
> + tc qdisc add dev eth0 parent 1:42 handle 42: sfq perturb 20
> + tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw
> RTNETLINK answers: Invalid argument
> + iptables -t mangle -N to-dsl
>
> Any clues?
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers: Invalid

[Flemming Frandsen]

Muthukumar S wrote:

>On 1/10/06, Flemming Frandsen <ff@nrvissing.net> wrote:
>  
>
>>When I run this:
>>tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw
>>
>>I get:
>>RTNETLINK answers: Invalid argument
>>    
>>
>
>You are missing the flowid. For example
>tc filter add dec eth0 parent 1: protocol ip prio 1 handle 1 fw flowid 1:42
>  
>

No, no I'm not, I'm using iptables like this:

...
iptables -t mangle -A from-dsl-eth1 -d 10.48.6.0/24 -j MARK --set-mark 
0x14806
iptables -t mangle -A from-dsl-eth1 -d 10.48.6.0/24 -j RETURN
tc class add dev eth1 parent 1:1 classid 1:4806 htb rate 1200mbit burst 
15k prio 10
tc qdisc add dev eth1 parent 1:4806 sfq perturb 21
...

That means that packets with --set-mark 0x14806 get put into classid 1:4806

The RETURN rule means that I can have a -j LOG at the end of my chain to 
figure out what didn't get matched, I just wish you could say -j 
MARK,RETURN in the same rule.

The funny thing that I realized after sending the original mail is that 
the shaper works, it classifies the traffic correctly, eventhough the tc 
filter command moans about an invalid argument.


It would be very nice to either get a usable error message or have tc 
shut up about the non-error.



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers: Invalid

[Andy Furniss]

Flemming Frandsen wrote:
> When I run this:
> tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw
> 
> I get:
> RTNETLINK answers: Invalid argument

As I already said - you don't need handle 1

Andy.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers: Invalid

[Andy Furniss]

Flemming Frandsen wrote:

> tc class add dev eth1 parent 1:1 classid 1:4806 htb rate 1200mbit burst 
> 15k prio 10

1200mbit with 15k burst won't work.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers:

[Flemming Frandsen]

>> tc class add dev eth1 parent 1:1 classid 1:4806 htb rate 1200mbit burst
>> 15k prio 10
>
> 1200mbit with 15k burst won't work.

Good thing too, because it's typo, I don't really have an Internet link in
the Gb/s, it ought to say 1200kbit.


>> tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw
>> RTNETLINK answers: Invalid argument
>
> As I already said - you don't need handle 1

I tried removing it, but it didn't make any difference.

Am I correct in assuming that the reason that the 'parent 1:' part isn't
needed is because it comes from the mark?

-- 
Flemming Frandsen, NrVissing.Net administrator.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers:

[Andy Furniss]

Flemming Frandsen wrote:

>>>tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1 fw
>>>RTNETLINK answers: Invalid argument
>>
>>As I already said - you don't need handle 1
> 
> 
> I tried removing it, but it didn't make any difference.
> 
> Am I correct in assuming that the reason that the 'parent 1:' part isn't
> needed is because it comes from the mark?
>

Remove handle 1 not parent 1:

In the context of fw handle 1 tells the filter to match mark 1.

Andy.




_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers:

[Flemming Frandsen]

Jody Shumaker wrote:
> I have never seen anything coming from the mark unless you specify it.  

I have.


> I'm honestly not really sure how setting a mark of 0x14806 can 
> automatically  set it to go to flowid 1:4806.

Because someone wrote it to do that, a mark of 0xdadface will map to 
flowid dad:face.


> I'm fairly sure you need 
> either a CLASSIFY target, or a tc filter to use the mark to  put it in a 
> specific classid. Is there something I'm missing here?

I'm pretty sure you are, I have it working here at my end.

The CLASSIFY target of iptables is something I have overlooked, it looks 
like it does exactly the same thing except with a slightly different and 
less obscure syntax.

I'll change my script to use CLASSIFY in stead, it seems a lot nicer.


> I'm curious 
> because you said it's working as it is right now, and would like to know 
> if there's something I'm just not familiar with.  This then makes me 
> wonder, what do you want this command to do? If its erroring an dnot 
> doing anything, but as you claim everything is working correctly... then 
> what do you need this for?

First the error, it was because I had "handle 1" in there, just like 
Andy said.


The trick is that this:
iptables -t mangle -A to-dsl -s $subnet -j MARK --set-mark $mark

... sets a mark that this:
tc filter add dev $uplink parent 1: protocol ip prio 1 fw

... uses to hit this directly:
tc class add dev $uplink parent 1:1 classid $class htb \
  ceil $userUpCeil rate $userUpRate burst 15k prio 10


Without any inbetween duplication of information, but so does CLASSIFY, 
so I'll just use that later on, thanks.




_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc filter add ... fw returns RTNETLINK answers:

[Jody Shumaker]

[-- Attachment #1.1: Type: text/plain, Size: 1108 bytes --]

On 1/13/06, Flemming Frandsen <ff@nrvissing.net> wrote:
>
> Jody Shumaker wrote:
> > I have never seen anything coming from the mark unless you specify it.
>
> I have.
>
>
> > I'm honestly not really sure how setting a mark of 0x14806 can
> > automatically  set it to go to flowid 1:4806.
>
> Because someone wrote it to do that, a mark of 0xdadface will map to
> flowid dad:face.


Interesting, learn something new every day. I was guessing I was missing
something since you had stated it was working, but was curious as to what.
I'll have to keep this feature in mind.


> I'll change my script to use CLASSIFY in stead, it seems a lot nicer.


Just as a warning,  I recall users having some issues with classify in the
past, so your current setup  may not seem as nice, it might still be
better.  In particular I seem to recall issues with  matching targets more
than 1 level deep. For example if you have 1:10  10:100 and 100:1000, you
can't have classify target the 100:1000.  This behavior might have changed
though.

As usual, if it ain't broke, don't fix it?

- Jody

[-- Attachment #1.2: Type: text/html, Size: 1607 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc