IPv4总长度超过数据包长度-始终为8.0.69.0

Question

我有一个问题...我们正在网络中离线捕获数据包，但收到很多“ IPv4总长度超过数据包长度”的错误，并且总是来自8.0.69.0。 该IP是虚假的，目标似乎是0.x，5.x或1.x，即也无效。 有些Google搜寻似乎暗示其他人在使用GRE / NAT方案时也看到了8.0.69.0。有谁知道这可能是什么吗？

PCAP上传了here。

Answer 1

这是数据包as per the answers when you asked this on the Wireshark Q&A site中一个额外的怪异标题。

Answer 2

错误是准确的

错误“ IPv4的总长度超过了数据包的长度”表示它的确切含义：IPv4数据包中的字节数超过了整个帧记录的字节数。

查看字段

我们可以同时指定帧长度（frame.len，frame.cap_len）和IP长度（ip.len）两个字段，以更深入地了解这一点：

$ tshark -r exceed-length.pcap -T fields -e frame.len -e frame.cap_len -e ip.len
1478    1478    3114
1536    1536    3114
1476    1476    13615
1399    1399    13781
1478    1478    3114
228     228     13615
195     195     13615
1478    1478    3114
1476    1476    13615
1478    1478    3114
265     265     3114
505     505     3114
1478    1478    3114
88      88      33514
1478    1478    3114
1478    1478    3114
1478    1478    3114

我们可以看到，每个帧的帧长度都超出了数据包长度，有时甚至超出了一个数量级。

这是什么原因造成的？

当捕获程序以pcap格式保存数据包时（如该文件一样），它会在每个数据包前加上其捕获的帧的长度（frame.cap_len），实际帧长（ frame.len）并捕获），以及时间戳。在大多数情况下，frame.cap_len和frame.len完全没有区别，在这里也没有。

如何修复？

如果您想手动edit the hex设置包的长度，有可能使该错误消失。

下一步

“ IPv4总长度超过数据包长度”很有可能是您实际遇到的问题。仅仅因为您在Wireshark中看到了专家信息，并不一定意味着它有意义。您应该继续进行故障排除。

Answer 3

事实证明这是额外的封装层。 答案是删除开头的22个字节，并揭示其中正确形成的数据包。非常感谢