tc filter fw and 2.6.26.7 problem - Networking

This is a discussion on tc filter fw and 2.6.26.7 problem - Networking ; 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 ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: tc filter fw and 2.6.26.7 problem

  1. 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.

  2. Re: tc filter fw and 2.6.26.7 problem

    "Zibi K." wrote in message
    news:gekb5a$2hn$1@atlantis.news.neostrada.pl...
    > 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 ?


    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).



  3. Re: tc filter fw and 2.6.26.7 problem

    Zibi K. wrote:
    > 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 ?


    Did you do

    tc qdisc add dev eth0 root handle 1:0 htb

    first?

    It works for me, older kernel though.

  4. Re: tc filter fw and 2.6.26.7 problem

    D. Stussy wrote:

    > 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).


    Try using different prio/pref for different filter protocols.


  5. Re: tc filter fw and 2.6.26.7 problem

    "Andy Furniss" wrote in message
    news:geqr9j$vhf$2@localhost.localdomain...
    > D. Stussy wrote:
    > > 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).
    >
    > Try using different prio/pref for different filter protocols.


    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.



  6. Re: tc filter fw and 2.6.26.7 problem

    D. Stussy wrote:
    > "Andy Furniss" wrote in message
    > news:geqr9j$vhf$2@localhost.localdomain...
    >> D. Stussy wrote:
    >>> 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).
    >> Try using different prio/pref for different filter protocols.

    >
    > 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.


    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.

  7. Re: tc filter fw and 2.6.26.7 problem

    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

  8. Re: tc filter fw and 2.6.26.7 problem

    "Andy Furniss" wrote in message
    news:ges4ak$4l5$1@localhost.localdomain...
    > D. Stussy wrote:
    > > "Andy Furniss" wrote in message
    > > news:geqr9j$vhf$2@localhost.localdomain...
    > >> D. Stussy wrote:
    > >>> 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).
    > >> Try using different prio/pref for different filter protocols.

    > >
    > > 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.
    >
    > 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.


    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.

    > 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.


    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.



  9. Re: tc filter fw and 2.6.26.7 problem

    Andy Furniss napisał/a:

    > Did you do
    >
    > tc qdisc add dev eth0 root handle 1:0 htb
    >
    > first?

    yes

    --
    Pozdrawiam
    Zibi K.

  10. Re: tc filter fw and 2.6.26.7 problem

    Zibi K. wrote:
    > Andy Furniss napisał/a:
    >
    >> Did you do
    >>
    >> tc qdisc add dev eth0 root handle 1:0 htb
    >>
    >> first?

    > yes
    >


    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.

  11. Re: tc filter fw and 2.6.26.7 problem

    Andy Furniss napisał/a:

    > 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.


    I will try 2.6.27 and new iproute2
    Then 2.6.25 with iproute2

    We'll see

    --
    Pozdrawiam
    Zibi K.

  12. Re: tc filter fw and 2.6.26.7 problem

    Zibi K. napisał/a:

    > I will try 2.6.27 and new iproute2


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

    --
    Pozdrawiam
    Zibi K.

  13. Re: tc filter fw and 2.6.26.7 problem

    "Andy Furniss" wrote in message
    news:ges4ak$4l5$1@localhost.localdomain...
    > Try using different prio/pref for different filter protocols.


    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....



+ Reply to Thread