Bug 584913 - tc generates a wrong filter match for IPv6 "priority"
tc generates a wrong filter match for IPv6 "priority"
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: iproute (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Petr Šabata
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-22 13:33 EDT by Peter Bieringer
Modified: 2010-06-28 04:20 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 586112 (view as bug list)
Environment:
Last Closed: 2010-06-28 04:20:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2010-04-22 13:33:04 EDT
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
Comment 1 Fedora Update System 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
Comment 2 Marcela Mašláňová 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.
Comment 3 Peter Bieringer 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.
Comment 4 Marcela Mašláňová 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?
Comment 5 Peter Bieringer 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 6 Fedora Update System 2010-05-04 02:24:36 EDT
iproute-2.6.29-5.0.20091009gitdaf49fd6.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Peter Bieringer 2010-05-04 03:23:34 EDT
Why is a still buggy version pushed to stable repository?
Comment 8 Marcela Mašláňová 2010-05-04 03:40:54 EDT
(In reply to comment #7)
> Why is a still buggy version pushed to stable repository?    

I removed it from updates completely. Shouldn't go there.

Anyway I was trying reproduce this issue. I was able to obtain the same output as you only on RHEL-5 machine. On all others (F-11, F-12, F-13, rawhide) I have RTNETLINK message. I agree this is broken and when I have a time, I'll try to fix it.
Comment 9 Fedora Admin XMLRPC Client 2010-06-16 07:57:37 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Petr Šabata 2010-06-28 04:20:07 EDT
Fixed in rawhide:  2.6.34-2

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