I had posted a query (please see e-mail below) about "marking packets that
have IP Options," some time back. After further probing (and with some help
from Don Cohen), the problem seems to be with the u32 filter rather than
dsmark. The bug is in how u32 handles the IP header length (it probably
assumes a fixed 20 byte header!) -- if I just use the IP header fields for
classification, it works and packets (with IP Options) get marked, however,
if any transport protocol header field (such as dport) is used for
classification, u32 fails! Unfortunately, I haven''t been able to
exactly
locate where in the code lies the bug. Please let me know if someone has
dealt with this problem earlier.
Thanks a lot!
Kaustubh
-----Original Message-----
From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]On
Behalf Of Kaustubh Phanse
Sent: Tuesday, January 28, 2003 3:38 PM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] Marking packets with IP Options field
Hello!
In our experiment, we are trying to mark IP packets at a source host. Some
of these packets have a 28-byte "IP Options" field, hence a 48-byte IP
header. We observed (using ethereal) that the tc script at the source
appropriately marks the packets that DO NOT have an "IP Options" field
(i.e., regular 20 byte header), however, all the packets with the "IP
Options" field do not get marked! The DSCP remains 0x00. We are using u32
filter to classify the packets, dsmark for marking, and HTB to schedule the
packets. Is there any such known problem for packets with "IP Options"
field??
Any help in this matter is much appreciated.
Thank you
regards
Kaustubh
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/