Bug 586112 - tc generates a wrong filter match for IPv6 "priority"
tc generates a wrong filter match for IPv6 "priority"
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: iproute (Show other bugs)
6.0
All Linux
high Severity medium
: rc
: ---
Assigned To: Petr Šabata
Zbysek MRAZ
:
Depends On:
Blocks: 519903
  Show dependency treegraph
 
Reported: 2010-04-26 16:08 EDT by Peter Bieringer
Modified: 2013-07-03 09:11 EDT (History)
6 users (show)

See Also:
Fixed In Version: iproute-2.6.32-10.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 584913
: 751285 (view as bug list)
Environment:
Last Closed: 2010-11-10 15:41:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
right filter for IPv6 priority (1.28 KB, patch)
2010-06-09 09:51 EDT, Petr Lautrbach
no flags Details | Diff

  None (edit)
Description Peter Bieringer 2010-04-26 16:08:18 EDT
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@fedoraproject.org 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@redhat.com 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@bieringer.de 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@redhat.com 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@bieringer.de 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.
Comment 2 RHEL Product and Program Management 2010-04-26 17:26:54 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Petr Lautrbach 2010-06-09 09:51:23 EDT
Created attachment 422553 [details]
right filter for IPv6 priority

IPv6 traffic class/priority is not aligned to whole bytes, but starts at 5th bit.

This patch adds new function which is intended just for parsing priority/traffic class.
static int parse_ip6_class(int *argc_p, char ***argv_p, struct tc_u32_sel *sel)

Results with patched version seems ok, works for me. Please review and test this.

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

# tc -s filter show dev eth0
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 01100000/0ff00000 at 0 (success 0 )
Comment 4 Marcela Mašláňová 2010-06-15 09:13:03 EDT
Would you mind test it and tell us whether this patch fixed your issue?
Comment 5 Peter Bieringer 2010-06-21 17:13:18 EDT
Where can I download binary RPM iproute-2.6.32-6.el6 for testing?
Comment 6 Marcela Mašláňová 2010-06-22 01:23:18 EDT
We do not provide test rpms, but this will be included in next snapshot (hopefully). Also this patch was added into rawhide.
Comment 7 Peter Bieringer 2010-06-23 14:51:57 EDT
rebuilded http://download.fedora.redhat.com/pub/fedora/linux/development/rawhide/source/SRPMS/iproute-2.6.34-2.fc14.src.rpm and run test on Fedora 12, match is proper generated and match e.g. ping6 $DST -Q 11 (just note, ping6 understands hexadecimal here...)
Comment 10 Petr Šabata 2010-07-22 09:54:12 EDT
Build 2.6.32-10 now includes the IP6 Priority header patch for 'tc'.
Comment 14 releng-rhel@redhat.com 2010-11-10 15:41:05 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.