与Linux tc过滤器u32匹配的数据包数据有效载荷不一致-有人可以解释吗？

我只想提出一些建议，因为我真的不明白-为什么-是这种情况。

当服务器向其发出常规GET请求时，“ HTTP”响应的TCPDUMP输出（tcpdump -s0 -XXnni eth0 tcp端口80）进一步向下。我想做的是使用Linux u32 tc过滤器匹配TCP ack数据包的内容，查找字符串'HTTP / 1。[01] TCP ack数据包的数据有效负载中的200“（换句话说，寻找典型的“ HTTP / 1.0 200 OK”响应或“ HTTP / 1.1 200 OK”响应）。

这是tc filter命令的一个片段-这可能有助于将内容放在上下文中：

tc filter add dev eth0 parent ffff: protocol ip u32 \
  match ip protocol 6 0xff \
  match ip sport 80 0xffff \
  match u8 0x10 0xff at 33 \
  match u32 0x48545450 0xffffffff at 52 \
  match u32 0x2f312e31 0xfffffffe at 56 \
  match u32 0x20323030 0xffffffff at 60 \
<do something>

最后3个“ match u32”行将匹配“ HTTP / 1.0 200”或“ HTTP / 1.1 200”，而u8则匹配TCP ack标志，其他匹配源端口80协议TCP。

我的查询是-为什么在两个不同的Linux机器上，我必须将数字52、56和60更改为40、44和48？（从偏移量中减去12）。它在我家里的Slackware Linux机器上接缝，我必须使用52、56和60，而在RedHat / CentOS服务器上，我必须使用40、44和48。

这样做的原因是简单的; 比较每个服务器的这两个TCPDUMP：

Slackware: 0x0000:  0040 63c9 c3a0 0018 7d05 dd11 0800 4500  .@c.....}.....E.
           0x0010:  05be d41c 0000 3606 9ea2 4266 0963 c0a8  ......6...Bf.c..
           0x0020:  000a 0050 a278 e948 dcdb fa41 ac84 8010  ...P.x.H...A....
           0x0030:  0059 3cb2 0000 0101 080a 9380 9172 0008  .Y<..........r..
           0x0040:  3bea 4854 5450 2f31 2e31 2032 3030 204f  ;.HTTP/1.1.200.O

RedHat or: 0x0000:  0016 3e32 3fcf 0010 dbff 2050 0800 4500  ..>2?......P..E.
CentOs:    0x0010:  0554 cf64 0000 3706 e08b 4266 0969 0a64  .T.d..7...Bf.i.d
           0x0020:  7881 0050 b316 c917 2062 b4a8 cff4 5018  x..P.....b....P.
           0x0030:  005a a17f 0000 4854 5450 2f31 2e31 2034  .Z....HTTP/1.1.4
           0x0040:  3034 204e 6f74 2046 6f75 6e64 0d0a 436f  04.Not.Found..Co

如您所见，在两种情况下，“ HTTP”部分开始的偏移点（包数据有效负载）是不同的。为什么是这样？会导致什么呢？

在此先感谢任何可以向我解释这个奥秘的人。

找到了答案。启用TCP时间戳会引入12个字节的额外报头信息，从而导致偏移量差异。

您可以通过执行以下操作在Linux中打开/关闭它们：

echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_timestamps

还可以通过以下操作查看它们是否打开/关闭：

cat /proc/sys/net/ipv4/tcp_timestamps

我发现这可以解决问题。

http://linux-tc-notes.sourceforge.net/tc/doc/cls_u32.txt

标头偏移

IP标头（和其他标头）的长度是可变的。如果您尝试使用“匹配”来查看后面的标头中的值，则会产生问题-您不知道它在哪里。这不是一个不可能的问题，因为IP数据包中的每个标头都包含一个长度字段。u32的“标头偏移”功能使您可以从数据包中提取该长度，然后将其添加到“匹配”选项中指定的偏移中。

下面是它的工作原理。回想一下match选项如下所示：

match u32 VALUE MASK at OFFSET

我之前说过，OFFSET告诉内核数据包中的哪个单词要与VALUE比较。该声明是一种简化。可以将其他两个值添加到OFFSET以确定要使用的单词。这两个值均以0开头，但是当“链接”选项调用另一个过滤器列表时，可以修改它们。所做的任何修改仅在执行被调用的过滤器列表时适用，因为如果被调用的过滤器列表无法对数据包进行分类，则将还原旧值。这是两个值和我称之为的名称：

permoff     This value is unconditionally added to every OFFSET
        that is done in the destination link, ie that one
    that is called.  This includes calculations of new
    permoff's and tempoff's.  Permoff's are cumulative
    in that if the destination link calls another link
    and calculates a new permoff, the result is added to
    this one.

tempoff A "match" option in the destination link can
        optionally add this value its OFFSET.  Tempoff's are
    temporary, in that it does not apply to any links the
    destination link calls.  It also does not effect the
    calculation of OFFSET's for new permoff's and
    tempoff's.

时间为例。考虑以下命令：

# tc filter add dev eth0 parent 999:0 protocol ip prio 99 u32 \
    link 1: offset at 0 mask 0f00 shift 6 plus 0 eat \
match ip protocol 6 ff

match表达式选择tcp数据包（这是IP协议6）。如果我们有协议6，则执行过滤器1：0。现在，剩下的事情：

offset  This signals that we want to modify permoff or tempoff
        if the link is executed.  If this is not present,
    neither permoff nor tempoff are effected - in other
    words the target of the link inherits the current
    permoff and tempoff.

at 0    This says the 16 bit word that contains the value we
        are going to use to calculate permoff or tempoff lives
    offset 0 the IP packet - ie at the start of the packet.
    This offset must be even.  If not specified 0 is used.

mask 0f00   This mask (which is in hex) is bit-wise anded with the
        16 bit word extracted from the packet header.  It
    isolates the header length from the rest of the
    information in the word.  If not specified 0 is used
    for the extracted value.

shift 6 This says the word extracted is to be divided by 64
        after being masked.  If not present the value is not
    shifted.

plus 0  After extracting the word, masking it and dividing it by
        64, this value is now added to it.  If not present is
    assumed to be 0.

eat     If this is present we are calculating permoff, and the
        result of the calculation above is added to it.  Tempoff
    is set to 0 in this case.  If this is not present we are
    calculating tempoff, and the result of the calculation
    becomes tempoff's new value.  Permoff is not altered in
    this case.