tc filter fw and 2.6.26.7 problem

Hi !
I have only one filter like this:
tc filter add dev eth0 parent 1: protocol ip fw

I got :
RTNETLINK answers: Invalid argument
We have an error talking to the kernel

Why ?

Next, when I do "tc filter show dev eth0" i got:
filter parent 1: protocol ip pref 49152 fw

and it's working fine ( testing on only one comp.)

I want to use htb with ipmark

My conf:
kernel 2.6.26.7
iptables-1.4.2.
iproute-2.6.26
patche ipmark,ipp2p,tarpit,route,imq,layer7

--
Zibi K.

"Zibi K." <zibi@jutra.pl> wrote in message
news:gekb5a$2hn$1@atlantis.news.neostrada.pl...[color=blue]
> Hi !
> I have only one filter like this:
> tc filter add dev eth0 parent 1: protocol ip fw
>
> I got :
> RTNETLINK answers: Invalid argument
> We have an error talking to the kernel
>
> Why ?[/color]

I get the same error ("error talking to the kernel") when I try to install
filter rules for IPv6 that are the same as my IPv4 rules that work. I
believe that is the standard response that indicates that the kernel doesn't
support the choice. I'm using a 2.6.27.4 kernel (the most current release).

Zibi K. wrote:[color=blue]
> Hi !
> I have only one filter like this:
> tc filter add dev eth0 parent 1: protocol ip fw
>
> I got :
> RTNETLINK answers: Invalid argument
> We have an error talking to the kernel
>
> Why ?[/color]

Did you do

tc qdisc add dev eth0 root handle 1:0 htb

first?

It works for me, older kernel though.

D. Stussy wrote:
[color=blue]
> I get the same error ("error talking to the kernel") when I try to install
> filter rules for IPv6 that are the same as my IPv4 rules that work. I
> believe that is the standard response that indicates that the kernel doesn't
> support the choice. I'm using a 2.6.27.4 kernel (the most current release).[/color]

Try using different prio/pref for different filter protocols.

"Andy Furniss" <spam@andyfurniss.entadsl.com> wrote in message
news:geqr9j$vhf$2@localhost.localdomain...[color=blue]
> D. Stussy wrote:[color=green]
> > I get the same error ("error talking to the kernel") when I try to[/color][/color]
install[color=blue][color=green]
> > filter rules for IPv6 that are the same as my IPv4 rules that work. I
> > believe that is the standard response that indicates that the kernel[/color][/color]
doesn't[color=blue][color=green]
> > support the choice. I'm using a 2.6.27.4 kernel (the most current[/color][/color]
release).[color=blue]
>
> Try using different prio/pref for different filter protocols.[/color]

OK, but I don't see how that would make a difference. Filter rules with the
same priority are simply stored and traversed in the order they were issued.

D. Stussy wrote:[color=blue]
> "Andy Furniss" <spam@andyfurniss.entadsl.com> wrote in message
> news:geqr9j$vhf$2@localhost.localdomain...[color=green]
>> D. Stussy wrote:[color=darkred]
>>> I get the same error ("error talking to the kernel") when I try to[/color][/color]
> install[color=green][color=darkred]
>>> filter rules for IPv6 that are the same as my IPv4 rules that work. I
>>> believe that is the standard response that indicates that the kernel[/color][/color]
> doesn't[color=green][color=darkred]
>>> support the choice. I'm using a 2.6.27.4 kernel (the most current[/color][/color]
> release).[color=green]
>> Try using different prio/pref for different filter protocols.[/color]
>
> OK, but I don't see how that would make a difference. Filter rules with the
> same priority are simply stored and traversed in the order they were issued.[/color]

ISTR finding a case where either specifying the same or maybe not
specifying prio/pref with the same protocol but different match types
resulted in the order of entry not being followed.

If order matters in your filter rules you should really be specific.

The point above about prio/pref and different protocols still seems to
be the case - you get an error if you specify the same prio for rules
with different protocols, whereas you get away with it if the protocol
is the same.

eg.

bash-3.2# tc qdisc add dev eth0 root handle 1:0 htb
bash-3.2# tc filter add dev eth0 parent 1: prio 1 protocol arp u32 match
u32 0 0 flowid 1:1
bash-3.2# tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match
ip src 192.168.0.0/24 flowid 1:2
RTNETLINK answers: Invalid argument
We have an error talking to the kernel

Works without prio or different prios, but would work as it is if both
protocols were the same and the matches were different (but as I say
above the order of entry may != order of evaluation in some cases.

Andy Furniss wrote:

snip.

I don't have ipv6 setup on my network, but this works for me.

bash-3.2# tc qdisc add dev eth0 root handle 1:0 htb
bash-3.2# tc filter add dev eth0 parent 1: prio 1 protocol ipv6 u32
match u32 0 0 flowid 1:1
bash-3.2# tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match
u32 0 0 flowid 1:2

"Andy Furniss" <spam@andyfurniss.entadsl.com> wrote in message
news:ges4ak$4l5$1@localhost.localdomain...[color=blue]
> D. Stussy wrote:[color=green]
> > "Andy Furniss" <spam@andyfurniss.entadsl.com> wrote in message
> > news:geqr9j$vhf$2@localhost.localdomain...[color=darkred]
> >> D. Stussy wrote:
> >>> I get the same error ("error talking to the kernel") when I try to[/color]
> > install[color=darkred]
> >>> filter rules for IPv6 that are the same as my IPv4 rules that work. I
> >>> believe that is the standard response that indicates that the kernel[/color]
> > doesn't[color=darkred]
> >>> support the choice. I'm using a 2.6.27.4 kernel (the most current[/color]
> > release).[color=darkred]
> >> Try using different prio/pref for different filter protocols.[/color]
> >
> > OK, but I don't see how that would make a difference. Filter rules with[/color][/color]
the[color=blue][color=green]
> > same priority are simply stored and traversed in the order they were[/color][/color]
issued.[color=blue]
>
> ISTR finding a case where either specifying the same or maybe not
> specifying prio/pref with the same protocol but different match types
> resulted in the order of entry not being followed.
>
> If order matters in your filter rules you should really be specific.[/color]

Order within an address family does matter to my rules. Order of address
family rulesets does not. However, Linux is "dual stack" which means
PARALLEL stacks, so there's no way that one ruleset could match the other -
the address families are mutually exclusive.
[color=blue]
> The point above about prio/pref and different protocols still seems to
> be the case - you get an error if you specify the same prio for rules
> with different protocols, whereas you get away with it if the protocol
> is the same.
>
> eg.
>
> bash-3.2# tc qdisc add dev eth0 root handle 1:0 htb
> bash-3.2# tc filter add dev eth0 parent 1: prio 1 protocol arp u32 match
> u32 0 0 flowid 1:1
> bash-3.2# tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match
> ip src 192.168.0.0/24 flowid 1:2
> RTNETLINK answers: Invalid argument
> We have an error talking to the kernel
>
> Works without prio or different prios, but would work as it is if both
> protocols were the same and the matches were different (but as I say
> above the order of entry may != order of evaluation in some cases.[/color]

I'll test this (didn't have time to do that yesterday), but if true, it
indicates a seious FLAW in the design. Granted that other AFs may not be
mutually exclusive, but these two are.

Andy Furniss napisał/a:
[color=blue]
> Did you do
>
> tc qdisc add dev eth0 root handle 1:0 htb
>
> first?[/color]
yes

--
Pozdrawiam
Zibi K.

Zibi K. wrote:[color=blue]
> Andy Furniss napisał/a:
>[color=green]
>> Did you do
>>
>> tc qdisc add dev eth0 root handle 1:0 htb
>>
>> first?[/color]
> yes
>[/color]

I am not sure then.

I have in the past managed to get tc to refuse valid stuff, but that's
been when I've been experimenting and maybe forgot to clean up between
tests with

tc qdisc del dev eth0 root

I tried on a 2.6.26.5 and it still works for me, though my iproute is
older than yours.

Andy Furniss napisał/a:
[color=blue]
> I am not sure then.
>
> I have in the past managed to get tc to refuse valid stuff, but
> that's been when I've been experimenting and maybe forgot to clean
> up between tests with
>
> tc qdisc del dev eth0 root
>
> I tried on a 2.6.26.5 and it still works for me, though my iproute
> is older than yours.[/color]

I will try 2.6.27 and new iproute2
Then 2.6.25 with iproute2

We'll see

--
Pozdrawiam
Zibi K.

Zibi K. napisał/a:
[color=blue]
> I will try 2.6.27 and new iproute2[/color]

.... but there is no iproute2 for 2.6.27 ;(

--
Pozdrawiam
Zibi K.

"Andy Furniss" <spam@andyfurniss.entadsl.com> wrote in message
news:ges4ak$4l5$1@localhost.localdomain...[color=blue]
> Try using different prio/pref for different filter protocols.[/color]

OK, I tried it with IPv4 and IPv6 as different priorities and it worked.
However, as noted in an earlier reply, I don't see any reason why they can't
have the same priority as they are mutually exclusive level 3 protocols and
therefore will never both match the same packet. It seems as if there's a
bug or design flaw somewhere....