tcpdump抓包，然后使用tcpreplay进行回放，出现了一些问题，目前找不到答案，暂时先记录在这里

我在使用tcpdump抓包后，然后将一部分数据包使用tcpreplay进行回放

对比原包和回放的包，我发现某些回放的包在帧尾会多出6个字节的0，这个简直匪夷所思，先记录下来，以后有时间再细细研究。

如果有知道的朋友，请留言，或者大家一起探讨也好，是由于文件格式问题还是由于什么问题。

下面是回放的数据包：

Ethernet II, Src: Vmware_6f:a9:b8 (00:0c:29:6f:a9:b8), Dst: Vmware_c0:00:08 (00:50:56:c0:00:08)

Destination: Vmware_c0:00:08 (00:50:56:c0:00:08)

Source: Vmware_6f:a9:b8 (00:0c:29:6f:a9:b8)

Type: IPv4 (0x0800)

Padding: 000000000000

下面是原数据包：

Ethernet II, Src: Vmware_6f:a9:b8 (00:0c:29:6f:a9:b8), Dst: Vmware_c0:00:08 (00:50:56:c0:00:08)

Destination: Vmware_c0:00:08 (00:50:56:c0:00:08)

Source: Vmware_6f:a9:b8 (00:0c:29:6f:a9:b8)

Type: IPv4 (0x0800)

时隔一周，已经有了答案，还是一些基础性问题，一些细节的小地方，可能不会引起大家的注意。

数据链路层相关介绍：

我们知道的是，数据链路层的传输如果不是全双工的，那么我们可以很清楚的知道，源端和发送端之间一定会存在一个碰撞问题，为了避免发生碰撞，有很多数据链路层协议，CSMA/CD就是以太网中一种重要的数据链路层协议，他在当今局域网中占据了统治地位。

RFC894

那么为了避免发生碰撞我们规定了最小的帧长，这个在以太网中通常是64字节，IP数据部分通常最小是46字节，这是RFC894标准所规定的最小的数据部分，如果数据部分小雨这个长度则会用0进行填充到最小帧长，在wireshark中就会显示为padding。我们看到上面则是填充的，由于在帧尾部会存在一个4字节的CRC验证，所以上面显示的帧长是60字节。

关于碰撞问题与帧长的关系，我会另外一篇帖子中详细介绍，至此，这个奇怪的问题解决了。