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
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
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.
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.
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?
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.
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.
Why is a still buggy version pushed to stable repository?
(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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fixed in rawhide: 2.6.34-2