From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Sat, 15 Apr 2006 16:14:50 +0000 Subject: Re: [LARTC] Problems matching by mac address Message-Id: <44411BFA.20503@dsl.pipex.com> List-Id: References: <48DC429CB053B64EAD91BDD1DE106A1152C021@es1.corp.commspeed.net> In-Reply-To: <48DC429CB053B64EAD91BDD1DE106A1152C021@es1.corp.commspeed.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Adam M. Towarnyckyj wrote: > Andy, > > Thanks for investigating so extensively. However, I'm an idiot and made > a fundamental mistake in networking that I should have realized in the > first place. I completely didn't think about the fact that the filter is > looking at the data link layer of the packet and that this gets changed > through each device. The test machine is set up behind a router. Also, > to answer your question, I'm using a download test app on a web server I > set up, so I'm basically using the same program for testing the > throughput each time. > > Sorry if I wasted anyone's time on this. With me, it's always something > obvious I missed and usually I don't realize until after I have > investigated every FAQ, Googled the hell out of the question, and posted > to a list. No problem - I don't know how to solve your new problem. I retried the test on a 2.6.15 with tc 051107 and the counters are OK now when I tc -s filter ls dev eth0 parent 12:0. One thing - I always considered the match 0x0800 0xFFFF at -2 to be redundant if you say protocol ip in the filter - so I ended up using the following, which I think is a bit easier to read with mac of target machine 00:C1:26:0F:04:AD. tc filter add dev eth0 protocol ip parent 12: prio 1 u32 \ match u16 0x00c1 0xffff at -14 \ match u32 0x260f04ad 0xffffffff at -12 \ flowid 12:10 Andy. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc