This site was migrated to a new server on Friday, April 28. If you run into any problems, please open a bug

OSQA is unmaintained. Help us figure out where to go from here.


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: 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:
(assuming that pppoe is added by ppp, the ppp0 interface comes up with the mtu 1492.
ipv4 (20) -> gre (4) -> ipv4 (20) -> tcp = 44bytes

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:
iptables -I POSTROUTING -t mangle -m u32 --u32 "46&0xFFFF=0x1194" -j LOG

for udp destination port (0x1194 = 4500, starting at position 46)

was not successfully.
i used nc, the receiving side was run with: nc -l -p 4500 -s showed the text output but did not increate the iptables counter

asked 16 Mar, 09:51

Steven_2's gravatar image

accept rate: 0%

edited 16 Mar, 14:07

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.:

iptables -I POSTROUTING -t mangle -m u32 --u32 "44&0xFFFF=0x1194" -j LOG

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.

permanent link

answered 16 Mar, 14:30

cmaynard's gravatar image

cmaynard ♦
accept rate: 20%

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.

(16 Mar, 15:21) Steven_2

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.

(16 Mar, 15:48) cmaynard ♦

yes you are right, my mistake

(16 Mar, 16:05) Steven_2
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 16 Mar, 09:51

question was seen: 156 times

last updated: 16 Mar, 16:05

p​o​w​e​r​e​d by O​S​Q​A