From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mohit Gupta" Date: Sat, 26 Oct 2002 19:07:33 +0000 Subject: [LARTC] Is this a kernel bug??? MIME-Version: 1 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C27D33.B3B876D0" Message-Id: List-Id: To: lartc@vger.kernel.org This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C27D33.B3B876D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.=20 $TC qdisc add $EGDEV handle 2:0 root dsmark indices 64 =20 # # 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=20 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. ------=_NextPart_000_0016_01C27D33.B3B876D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi
I am = encountering=20 what I suspect to be a bug in the kernel processing of
tc netlink=20 messages:

     I am using kernel version = 2.4.9 with=20 iproute2-current-001007
package. Everything works fine in the kernel. = Now I=20 open a netlink
socket with a user process, read the tc netlink = messages=20 generated by
the tc process and parse them.
What I see is that the = kernel=20 has already processed the messages (i.e.,
adds some default
values = for=20 example) before making them available to my = process.

   =20 Problem comes when I parse the tcindex messages. Here is an = excerpt
from the=20 examples in iproute2 diffserv distribution.

$TC qdisc add $EGDEV = handle=20 2:0 root dsmark indices 64

#
# The class mapping
#
$TC = filter=20 add $EGDEV parent 2:0 protocol ip prio 1=20 \
          handle 1 = tcindex=20 classid 2:1
$TC filter add $EGDEV parent 2:0 protocol ip prio 1=20 \
          handle 2=20 tcindex classid 2:2
$TC filter add $EGDEV parent 2:0 protocol = ip prio 1=20 \
          handle 3=20 tcindex classid 2:3
$TC filter add $EGDEV parent 2:0 protocol = ip prio 1=20 \
          handle 4=20 tcindex classid 2:4

When I parse the tcindex filter = messages I dont=20 see the handle and the
classid information. I only see the default = value that=20 are set by the
kernel for mask, shift and fall_through.
I SEE = >>=20 hash 64 mask 0xffff shift 0 fall_through

But when I do a >> = tc=20 filter ls dev eth0 parent 2:0, I see all the
handle - classid pair I = have=20 instantiated. I feel there is something
wrong in the way the tcindex = filter=20 messages are being processed by the
kernel. The handle and = classid=20 information is no longer there in the netlink

message when it is put = back on=20 the netlink socket by the kernel.
If = indeed does=20 anyone know how to fix this and if not then can
someone please tell = me how=20 the read the handle and classid information
for these = messages.

PS -=20 My process parses all the other tc messages=20 correctly.

Thanks,
Mog.

------=_NextPart_000_0016_01C27D33.B3B876D0-- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/