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/
