tc filter can't match ACK packets

ivanatora · 02-04-2009, 12:22 PM

Hello,
I'm trying to build some basic traffic shaper here, and I want to classify tcp packets with ACK flag set. I'm reading LARTC and I see that example there:

Code:

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match ip protocol 6 0xff \
     match u8 0x10 0xff at nexthdr+13 \
     flowid 1:3

Well, here is the filter I'm using and it won't assign any traffic to class 1:212:

Code:

tc filter add dev eth0 protocol ip parent 1: u32 \
match ip protocol 6 0xff \
match u8 0x10 0xff at nexthdr+13 \
classid 1:212

Flowid and classid are the same thing, right?
I'm watching the queues and I never see any traffic in 1:212.

Code:

# tc -s class show dev eth0                                                                                    
class hfsc 1: root 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
 period 0 level 2 

class hfsc 1:212 parent 1:21 sc m1 0bit d 0us m2 3000Kbit ul m1 0bit d 0us m2 8000Kbit 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
 period 0 level 0 

class hfsc 1:211 parent 1:21 sc m1 0bit d 0us m2 3000Kbit ul m1 0bit d 0us m2 8000Kbit 
 Sent 6583839 bytes 5738 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 2p requeues 0 
 period 3274 work 6580811 bytes rtwork 3542314 bytes level 0 

class hfsc 1:30 parent 1: sc m1 10000Kbit d 1.0s m2 1000Kbit ul m1 0bit d 0us m2 1000Kbit 
 Sent 7570 bytes 5 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
 period 4 work 7570 bytes rtwork 7570 bytes level 0 

class hfsc 1:21 parent 1: sc m1 0bit d 0us m2 8000Kbit 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
 period 3274 work 6580811 bytes level 1

Also I'm seeing in Wireshark there are ACK packets passing trough me.
What could I be doing wrong?

ivanatora · 02-10-2009, 01:29 PM

What happens when I put several 'match' lines in a single filter? Is it a logical AND of the results of the different matches? Also, is there a place where all matches are described and documented?
Is there an obvious reason why the following filter is not working:

Code:

tc filter add dev eth0 protocol ip parent 1: u32 match ip protocol 6 0xff \
match ip dst 192.168.0.34 \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
classid 1:202

Or this:

Code:

tc filter add dev eth0 protocol ip parent 1: u32 \
match ip tos 0x50 0xff \
match ip dst 192.168.0.34/32 \
classid 1:202

Assuming there is a class with ID 202 in the qdisc of the proper device.

bzyk · 02-10-2009, 03:11 PM

Hi.

This one works for me (very fine, on several machines, more than a couple of years);

# ACK < 64bit
$tc filter add dev $EXTIF protocol ip parent 1:0 prio 1 u32 match ip protocol 6 0xff match u8
0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:15

Please notice, that this work for ACK smaller than 64bit.

ivanatora · 02-10-2009, 03:27 PM

And what would you add to that rule if you wish to capture ACKs traveling from/to certain IP?

ivanatora · 02-10-2009, 03:44 PM

Ok, I found what is wrong - the rule insertion order. Ofcourse once the packet matches a rule it doesn't check for any rules after that. Untill now I assumed every new TC rule is appended at the end of the existing ones. And I had:

Code:

1) match ack packets to $host
2) match any other packets to $host

That order should ensure the ACK packets are matched first, and if the packet is not ACK it should fall into the second rule.
Well, it is exactly the opposite state! Every new TC rule is _inserted_ at the beginning of the rules. In that way my logic is totally busted: packets are first matched against the rule 2) and if they match the rule 1) doesn't get the chance at all.
The order of the inserted rules can be view with:

Code:

tc filter show dev eth0