Bug 584913 - tc generates a wrong filter match for IPv6 "priority"
Summary: tc generates a wrong filter match for IPv6 "priority"
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: iproute   
(Show other bugs)
Version: 12
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Petr Šabata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-22 17:33 UTC by Peter Bieringer
Modified: 2010-06-28 08:20 UTC (History)
3 users (show)

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


Attachments (Terms of Use)

Description Peter Bieringer 2010-04-22 17:33:04 UTC
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 07:37:04 UTC
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 07:41:25 UTC
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 09:35:33 UTC
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 12:11:06 UTC
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 13:51:12 UTC
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 06:24:36 UTC
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 07:23:34 UTC
Why is a still buggy version pushed to stable repository?

Comment 8 Marcela Mašláňová 2010-05-04 07:40:54 UTC
(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 11:57:37 UTC
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 08:20:07 UTC
Fixed in rawhide:  2.6.34-2


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