Bug 586112

Final RHEL6 should be also have fixed this issue  because of:

http://www.redhat.com/rhel/beta/
Next generation networking: comprehensive IPv6 support

# rpm -qf `which tc` 
iproute-2.6.32-3.el6.i686

# tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 1000Mbit
# tc filter add dev eth1 parent 1: protocol ipv6 u32 match ip6 priority 17 0xff
# tc -s filter show dev eth0
filter parent 1: protocol ipv6 pref 49152 u32 
filter parent 1: protocol ipv6 pref 49152 u32 fh 800: ht divisor 1 
filter parent 1: protocol ipv6 pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:3  (rule hit 0 success 0)
  match 11000000/ff000000 at 4 (success 0 ) 

=> and this match is wrong, see below


+++ This bug was initially created as a clone of Bug #584913 +++

Description of problem:
tc generates a wrong filter match for IPv6 "priority", the resulting match does not reflect the IPv6 header field proper.

Version-Release number of selected component (if applicable):
iproute-2.6.29-4.fc12.i686

How reproducible:
Always

Steps to Reproduce:
# tc filter add dev eth1 parent 1: protocol ipv6 u32 match ip6 priority 17 0xff flowid 1:3

  
Actual results:

filter parent 1: protocol ipv6 pref 49146 u32 
filter parent 1: protocol ipv6 pref 49146 u32 fh 806: ht divisor 1 
filter parent 1: protocol ipv6 pref 49146 u32 fh 806::800 order 2048 key ht 806 bkt 0 flowid 1:3  (rule hit 0 success 0)
  match 11000000/ff000000 at 4

Expected results:
  match 01100000/0ff00000 at 0

Additional info:
Real proper name for "priority" in IPv6 would be "Traffic Class" and this is defined as 8 Bits from Bit 4 to 11 (part of 1. and 2. byte)


Workaround: don't use priority until it works, use u32 match instead, e.g.
 u32 0x01100000 0x0ff00000 at 0

--- Additional comment from updates on 2010-04-23 03:37:04 EDT ---

iproute-2.6.29-5.0.20091009gitdaf49fd6.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/iproute-2.6.29-5.0.20091009gitdaf49fd6.fc12

--- Additional comment from mmaslano on 2010-04-23 03:41:25 EDT ---

I forgot create an update :( Please try to update to git snapshot which should contain few bug fixes and also current kernel headers for actual Fedora kernel. I don't have any F-12 anymore, so please let me know, whether there is still problem.

--- Additional comment from pb on 2010-04-24 05:35:33 EDT ---

Hmm, the RPM from https://bugzilla.redhat.com/show_bug.cgi?id=584913#c1 won't fix the problem

# rpm -q iproute
iproute-2.6.29-5.0.20091009gitdaf49fd6.fc12.i686

# tc filter add dev eth1 parent 1: protocol ipv6 u32 match ip6 priority 255 0xff flowid 1:3

# tc -s filter show dev eth1
filter parent 1: protocol ipv6 pref 49147 u32 
filter parent 1: protocol ipv6 pref 49147 u32 fh 805: ht divisor 1 
filter parent 1: protocol ipv6 pref 49147 u32 fh 805::800 order 2048 key ht 805 bkt 0 flowid 1:3  (rule hit 0 success 0)
  match ff000000/ff000000 at 4 (success 0 ) 
...

digging through the source code I believe that tc is at the moment not able to parse and define filtter for the IPv6 option proper at all:

Probably related code: tc/f_u32.c and marked line:

static int parse_ip6(int *argc_p, char ***argv_p, struct tc_u32_sel *sel)
{
        int res = -1;
        int argc = *argc_p;
        char **argv = *argv_p;

        if (argc < 2)
                return -1;

        if (strcmp(*argv, "src") == 0) {
                NEXT_ARG();
                res = parse_ip6_addr(&argc, &argv, sel, 8);
        } else if (strcmp(*argv, "dst") == 0) {
                NEXT_ARG();
                res = parse_ip6_addr(&argc, &argv, sel, 24);
        } else if (strcmp(*argv, "priority") == 0) {
                NEXT_ARG();
                res = parse_u8(&argc, &argv, sel, 4, 0);    <-!!!!!!!
        } else if (strcmp(*argv, "protocol") == 0) {
                NEXT_ARG();
                res = parse_u8(&argc, &argv, sel, 6, 0);
        } else if (strcmp(*argv, "flowlabel") == 0) {
                NEXT_ARG();
                res = parse_u32(&argc, &argv, sel, 0, 0);


Looks like the handler must be replaced for priority by a somehow splitted "u4" or something else.

--- Additional comment from mmaslano on 2010-04-26 08:11:06 EDT ---

Could you give me another hint? Which kernel do you use? I have 2.6.33 and higher and instead of some filter I have only RTNETLINK answers: Invalid argument

Also do you know which iproute version (and kernel) had worked?

--- Additional comment from pb on 2010-04-26 09:51:12 EDT ---

With kernel 2.6.32.9-70.fc12.i686 the filter setup works in prinicipially, iproute version is mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=584913#c3, but the F12 default one has the same problem.