Hi Peter, I was working on this problem and came up with a solution... Instead of using tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match tcp src 0x1f90 0xffff flowid 1:100 use : tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match ip dport 0x1f90 0xffff flowid 1:100 This works, because I think the mechanism of u32 is like : when it comes across 'match tcp' it maps this to nexthdr+ 0 ( you can see it with " tc filter show dev eth1" ) but when it comes across 'match ip <dport>' It maps to offset byte directly so when you do a tc filter show dev eth1 you see match PATTERN/MASK at 20( or whatever offset you specify, but note that it doesnt specify nexthdr+...) This works.. So I presume that there is something wrong with the implementation of nexthdr ..Maybe Jamal or Werner should look into it. Hope you get along.Feel free to ask for further clarifications. Suhail COMET GROUP http://www.comet.columbia.edu Columbia University New York Peter Frischknecht wrote: > I have spent a tremendous amount of time on this one, and I can reproduce > it. > > I set up all of my classes and queues. > Now is time for the filters. > > Let's say that I have a flowid 1:100 which is the handle of a queue with a > very small bounded isolated bandwidth allocation of 25Kbit. > > If I use the following filter: > > tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match ip src > 216.79.164.46 flowid 1:100 > > I get the correct throughtput of 25Kbit. > > However, if I attempt to filter by protocol instead, it does not work. > I will disregard the fact that this filter will manipulate both TCP and UDP > sessions destined to the specific port. > I am attaching to a server on port 8080 (0x1f90). > > tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match tcp src > 0x1f90 0xffff flowid 1:100 > > A connection to the above port will yield the default bandwidth of 10Mbit. > Not the desired effect. > > I have used many examples copied strainght out of the sources, in all of > them, the IP address matching works, but the TCP matching never does. > > Any help is greatly appreciated. > > Peter Frischknecht > Empowering Solutions, Inc. > http://www.empoweringsolutions.com > (864)654.6544 x103 Phone > (864)654.0022 Fax > > _______________________________________________ > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
