Alan Ford wrote: > I'm trying to understand how the wondershaper ACK match works. Can > somebody help me decode it? > > |tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > | match ip protocol 6 0xff \ > > TCP. Aye. > Do these start from the start of the IP header, or the TCP header? Ip header - there's no state information relayed between matches - so these matches cannot know that the protocol is TCP. > | match u8 0x05 0x0f at 0 \ > > If this is start of TCP header - source port is over 1280? First byte of ip packet, first nibble is version, second nibble is length in words. 0x45 is what it is normally - eg. 20 bytes ip header, no options. That is, this just makes sure there are no ip options on the packet. > | match u16 0x0000 0xffc0 at 2 \ > > Something about the destination port, I'm a bit confused by the > netmask. Surely not "under 64", which is how I'm reading it? > > Or, if this is from the start of the IP header, is this packet > length? Under 64 bytes? Might make more sense... Length below 64. TCP has no length field - and the only thing which separates an ACK packet with no data transmitted with it from an ACK packet which has data as well is indeed the packet length. > | match u8 0x10 0xff at 33 \ > > ??? > > Acknowledgement number starts with 0x10 ? ACK bit is on in TCP flags - and everything else is off. > | flowid 1:10 That should do it. However, I prefer to do the same thing in netfilter and then just use that information in the traffic control side. Example from a 'ferm' script: proto tcp tcp-flags ALL ACK length 0:63 MARK setmark 1; This one is almost identical to the one shown above and much easier to understand. -- Naked _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
