|
Hi
I am encountering what I suspect to be a bug in the kernel processing of tc netlink messages: I am using kernel version 2.4.9 with iproute2-current-001007 package. Everything works fine in the kernel. Now I open a netlink socket with a user process, read the tc netlink messages generated by the tc process and parse them. What I see is that the kernel has already processed the messages (i.e., adds some default values for example) before making them available to my process. Problem comes when I parse the tcindex messages. Here is an excerpt from the examples in iproute2 diffserv distribution. $TC qdisc add $EGDEV handle 2:0 root dsmark indices 64 # # The class mapping # $TC filter add $EGDEV parent 2:0 protocol ip prio 1 \ handle 1 tcindex classid 2:1 $TC filter add $EGDEV parent 2:0 protocol ip prio 1 \ handle 2 tcindex classid 2:2 $TC filter add $EGDEV parent 2:0 protocol ip prio 1 \ handle 3 tcindex classid 2:3 $TC filter add $EGDEV parent 2:0 protocol ip prio 1 \ handle 4 tcindex classid 2:4 When I parse the tcindex filter messages I dont see the handle and the classid information. I only see the default value that are set by the kernel for mask, shift and fall_through. I SEE >> hash 64 mask 0xffff shift 0 fall_through But when I do a >> tc filter ls dev eth0 parent 2:0, I see all the handle - classid pair I have instantiated. I feel there is something wrong in the way the tcindex filter messages are being processed by the kernel. The handle and classid information is no longer there in the netlink message when it is put back on
the netlink socket by the kernel.
If indeed does anyone know how to fix this and if not then can someone please tell me how the read the handle and classid information for these messages. PS - My process parses all the other tc messages correctly. Thanks, Mog. |
