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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/