From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julian Anastasov Date: Fri, 14 Dec 2001 12:56:57 +0000 Subject: Re: [LARTC] tc: u32 match in nexthdr not working? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Hello, On Fri, 14 Dec 2001, Lutz Pressler wrote: > Hi again, > > ok, did some tests: > > match ip sport 3128 does work (as does the more correct > match ip sport 3128 0xffff match ip protocol 0xff to only consider > TCP) - match tcp src 3128 does not. > > The difference as shown by tc filter show dev eth0 parent ffff: > is that ip sport -> "match 0c380000/ffff0000 at 20" > tcp src -> "match 0c380000/ffff0000 at nexthdr+0". > > This confirms my assumption, that nexthrd is broken. It confirms only that nexthdr does not work with your settings. Nothing more. Read carefully iproute2/README.iproute2+tc and particularly the last filter in this file. I agree, it is not documented very well. To use nexthdr you must use "offset" with hash table. U32 is universal (read line #2 in cls_u32.c), it does not know that you are using IPv4, so the value 20 can not be guessed. For this, "offset" is used to extract the iphdr->ihl value and to use it as a base for all nexthdr+ relative offsets. > at nexthdr+0 _should_ work with IP options present, "at 20" not, > correct? > > Lutz Regards -- Julian Anastasov _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/