难道是wireshark的问题?
原来在ethereal时代没有问题

要选#7 #10才明了

======================
last edit by Vader

好快的速度
没有明白vader的意思,是第二十帧吗?
附上trace

6是碎片的最后一帧，看上去挺合理的阿

引用:

原帖由 Vader 于 2007-3-29 01:08 发表
6是碎片的最后一帧，看上去挺合理的阿

IP layer flag set
more fragments:not set
这儿出了问题
应该为set,1

看hex显示界面,对应hex02

其他分析系统查看没有问题

这个应当是清空arp表后发出的一个icmp的大包

在传输的过程中进行了分片，四个分片的id标识相同

[ 本帖最后由 fishyxq 于 2007-3-30 10:45 编辑 ]

icmp及分片信息

第一个数据报

大家注意ip层以下几个字段

ip：identification=11520   
在发送数据报前，发送者会给每个数据报一个id值，2字节，唯一的表示数据报或流。目标主机将利用此id进行数据报的重组。当源主机的ip进程从上层的tcp或udp收到的用于分组的大块数据流时，如果对与传输介质而言过大，就将其分片，属于统一流的数据段分配同一id。
在3、4、5、6及后面大家可以看到id值都有相同，表示被分片。

ip：flags
标志比特，3bit
第0bit＝预留
第1bit＝0（可以分段）；1（不可分段）
第2bit＝0（最后一段）；1（分段未完）

ip：fragment offset＝
发送主机以段偏移值表示数据报在发送的数据流中的位置，即用同一ip表示发送多个数据报时的顺序号。发送主机总是给第一个数据报的偏移赋值o，而后续的则是传输介质中分段的mtu大小为基础的数值。
接受主机收到后用此偏移值将这些数据报重组成一个流或者检查流中的数据报是否丢失。

[ 本帖最后由 fishyxq 于 2007-3-30 13:11 编辑 ]

第二个

同上图相比，id相同，也是未完的分段，但是段偏移为1480。同上图值相减，可判断mtp为1480

[ 本帖最后由 fishyxq 于 2007-3-30 10:53 编辑 ]

引用:

原帖由 haiwanxue 于 2007-3-29 01:13 发表

IP layer flag set
more fragments:not set
这儿出了问题
应该为set,1

看hex显示界面,对应hex02

其他分析系统查看没有问题

那就是其他分析系统有问题
hex 02 的前三个bit，而不是全部字节

第三个，同上

最后一个，也就是上面两位大大讨论的地方


此处标志比特的第三个bit位为0，表示该段时数据流中的最后一个。

目标主机将接受的id相同的数据报再根据段偏移值进行顺序重组，此报由于标志比特位的第三个bit为0，所以放在最后。

打完收工。

此处不参与两位大大的讨论，仅给弟兄们做参看两位大大讨论的参考资料，呵呵！

部分资料提供于：tcp/IP primer plus 中文版
感谢haiwanxue 提供的 trace file,收之。

[ 本帖最后由 fishyxq 于 2007-3-30 11:19 编辑 ]

也算误导,也算疑惑,也算发现

同一个trace,decode info显示大相庭径,我当时只在wireshark下看echo request/reply

ethereal下你看了第三个包，wireshark下看了第6个，怎么会一样

为什么　用户sniffer 与thereal 打开上述数据包显示的不太一样啊？

学习了，我用wireshark打开的，请问一下图中下面有两个分栏：Frame(1026 bytes) Reassembled IPv4(5608 bytes),这是什么意思啊？

我的理解是：
当前选中的第6帧大小为1206个bytes，这个帧为分片帧（3、4、5、6帧），总共的大小为5608个bytes，详见7楼截图

请 老大能否给小弟说下
                1：什么是MTP
                 2:怎么判断这个是清空arp表后发出的一个icmp的大包？

                 3.为什么在传输的过程中进行了分片呢？ 不分片的大小是多少 ？？

    （新手）