[LARTC] Re: ACK Packet Detection

[Nuutti Kotivuori <naked@iki.fi>]

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/