for a traffic shaping experiment i would like to mark packets with iptables or tc on the ppp0 interface. the packet itself goes over a gre tunnel and ive been looking into finding out the exact location of the destination port within such a packet.
capturing with tcpdump like this: tcpdump -i ppp0 -nnXSs 0 -c 2 -w /tmp/gre-test.pcap proto gre
is shown in wireshark with these layers: frame -> linux cooked capture -> ipv4 -> gre -> ipv4 -> tcp
it looks like the "linux cooked capture" header is 32 bits long - now when writing tc rules, should i include these 8 bytes into my calculation or not?
theres a explanation what "linux cooked capture" is here: https://wiki.wireshark.org/SLL but im not sure which of the cases it could be.
assuming that the ipv4 headers come without options and therefore are 20bytes long i would calculate like this:
so starting at position 46 should begin the tcp destination port of the innermost packet.
but since my calculation does assume ipv4 as the first level and not linux cooked capture im not really sure which number it will be.
my first test:
for udp destination port (0x1194 = 4500, starting at position 46)
was not successfully.
it looks like the "linux cooked capture" header is 32 bits long - now when writing tc rules, should i include these 16bytes into my calculation or not?
To be clear, the Linux cooked capture header length is 16 bytes, not 32 bits.
I think you will need to change the offset to 44, e.g.:
u32 grabs 4 bytes, not 2 bytes, so you should grab the 4 bytes starting with the source port and then apply the mask to the upper 2 bytes to isolate the lower 2 bytes, which are the 2 bytes that comprise the destination port.
answered 16 Mar, 14:30