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字节。


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

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值