hi, 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. asked 16 Mar '17, 09:51  Steven_2 edited 16 Mar '17, 14:07 |
One Answer:
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 '17, 14:30  cmaynard ♦♦ |
thank you for the answer, seems that its working...but i need some sleep.
do you meant that 8 bytes and not 16 bytes like i wrote? in wireshark in the detail view it uses one line and goes from left to right up to the end.
You first wrote, "it looks like the "linux cooked capture" header is 32 bits long ...", but that's wrong. 32-bits is 4 bytes, not 16 bytes. You must have realized the header was actually 16 bytes though because you then continued with, "should i include these 16bytes into my calculation or not?". So, I merely thought that I'd clarify the length for the benefit of anyone else who might be reading and might otherwise be confused by these conflicting length values.
yes you are right, my mistake