谁能读懂UDP数据包,谢谢

hudeg632 · 发表于 2007-9-11 23:02:22

数据包信息:
数据包编号:                            000452
数据包长度:                            150
捕获长度:                            146
时间戳:                               2007-09-11 22:12:54.242183
以太网 - II                               [0/14]
目标地址:                            00:16:EC:31:A3

C  [0/6]
源地址:                               00:E0:FC:48:91:54  (Huawei Tach)  [6/6]
协议类型:                            0x0800  (Internet IP (IPv4))  [12/2]
IP - 因特网协议                            [14/20]
版本:                               4  [14/1]  0x00F0
头部长度:                            5  (20 字节)  [14/1]  0x000F
区分服务字段:                            0000 0000  [15/1]  0x00FF
      不同的服务代码:                      0000 00..  (缺省)  [15/1]  0x00FC
      传输协议忽略CE位:                   .... ..0.  (忽略)  [15/1]  0x0002
      拥塞:                            .... ...0  (不拥塞)  [15/1]  0x0001
总长度:                               132  (132 字节)  [16/2]
标识:                               0x12AE  (4782)  [18/2]
分段标志:                            000. ....  [20/1]  0x00E0
      保留:                            0... ....  [20/1]  0x0080
      分段:                            .0.. ....  (可能分段)  [20/1]  0x0040
      更多分段:                         ..0. ....  (最后一个段)  [20/1]  0x0020
分段偏移量:                            0  [20/2]  0x1FFF
生存时间:                            108  [22/1]
上层协议:                            17  (UDP)  [23/1]
校验和:                               0x4325  (正确)  [24/2]
源IP地址:                            222.247.88.66  [26/4]
目标IP地址:                            192.168.0.180  [30/4]
无IP选项                            [34/0]
UDP - 用户数据报协议                         [34/8]
源端口:                               6881  [34/2]
目标端口:                            6881  [36/2]
长度:                               112  [38/2]
检验和:                               0x266A  (正确)  [40/2]
额外数据:                                  [42/104]
字节数:                               104 bytes  [42/104]
FCS - 帧校验序列:
FCS:                               0x6E7B43C4  (计算出的)

额外数据
64 31 3A 61 64 32 3A 69 64 32 30 3A 30 CA CE AD 0C 8F 08 06 FF 0E 43 E6 17 FC 28 02 26 7C 1F B1 39 3A 69 6E 66 6F 5F 68 61 73 68 32 30 3A 38 39 72 42 80 A2 DB 1E 75 93 AA D6 89 FE 1A 6D E1 AE 6B 9F 65 31 3A 71 39 3A 67 65 74 5F 70 65 65 72 73 31 3A 74 32 3A 01 62 31 3A 76 34 3A 4C 54 01 02 31 3A 79 31 3A 71 65

想问一下这些额外数据是什么意思?

[ 本帖最后由 hudeg632 于 2007-9-11 23:05 编辑 ]

无影战士 · 发表于 2007-9-11 23:27:49

在"数据包"视图中"协议"列里显示的是BitTorrent, 可知这是一个BT数据包. 另外, 你在下面的十六进制解码视图的右边文本区可以很清楚的看到以下内容:

"d1:ad2:id20:0...�....:info_hash20:89rB......1:q9:get_peers1:t2:.b1:v4......1:y1:qe"

这是BT协议发起对等主机连接的请求.

其实经常看看BT使用时的数据包情况, 你就会发现"64 31 3A 61 64 32 3A 69 64 32 30"是多么熟悉的一个头信息.

hudeg632 · 发表于 2007-9-12 21:05:39

感谢你你回答．

这样的数据包过后，如果补请求连结的主机关了，网关就不断地发ＡＲＰ请求（持续很长一段时间，长达十几个小时），找这台机器．每秒１０包左右，这是正常的吗？我怎样做才能不让网关发这样的数据包，这个问题搞了我好久了．你能帮一下吗？

lnan · 发表于 2007-9-13 11:05:28

我在对ARP过程进行抓包的时候，遇到了同样的问题，再arp回复的时候，也是出现了“额外数据”，看了楼上的回答，我还是不明白，这个额外数据到底是什么?能在详细说说吗？以及在什么情况下会出现这种额外数据。

顺便表扬一下科来，这个“额外数据”再ethereal中是看不到的。

[ 本帖最后由 lnan 于 2007-9-13 11:08 编辑 ]

hudeg632 · 发表于 2007-9-13 21:00:23

哈哈,终于发现有朋友和我一样关心这个问题了.http://www.csna.cn/forum.php?mod ... 4672&sid=W2DhSo

请高人们解答.

[ 本帖最后由 hudeg632 于 2007-9-13 21:04 编辑 ]

无影战士 · 发表于 2007-9-13 21:05:05

建议你放一个数据包文件上来好分析,要包含你说的网关发送的ARP请求.

晕, 居然在同时发贴.

[ 本帖最后由无影战士于 2007-9-13 21:07 编辑 ]

无影战士 · 发表于 2007-9-13 21:08:49

原帖由 lnan 于 2007-9-13 11:05 发表
我在对ARP过程进行抓包的时候，遇到了同样的问题，再arp回复的时候，也是出现了“额外数据”，看了楼上的回答，我还是不明白，这个额外数据到底是什么?能在详细说说吗？以及在什么情况下会出现这种额外数据。
...

额外数据通常是一堆"00",就是用来填充空白的, 好让ARP包达到64字节长度.

lnan · 发表于 2007-9-14 09:16:55

首先非常感谢楼上的朋友回答我的问题，但是感觉您的回答不能让我完全理解，原因如下：

图片中是对一个ARP请求以及回应的抓包。

请求包中，数据包长度为64，捕获长度为42，这都是正常的。包中应该有28字节的填充，但是没有在图中显示出来。

回应包中，数据包长度是64字节，捕获长度是60，这也是正确的，应该有28字节的填充，但是在图中却显示出来了，这是为什么呢？

难道科来对ARP请求包和回应包的分析程度不一样吗？还是说这是科来的一个BUG呢？

[ 本帖最后由 lnan 于 2007-9-14 09:23 编辑 ]

lnan · 发表于 2007-9-16 22:13:45

问题还没有解决，继续顶～～～～

lnan · 发表于 2007-9-17 10:51:45

还有一个问题，同样是额外数据，为什么ARP请求包中的额外数据没有被捕获，而应答的额外数据被捕获了呢？

感谢菜鸟版主回答一下～～～

zhongheihu · 发表于 2009-7-11 10:28:53

谢谢！！！辛苦了！！！

谁能读懂UDP数据包,谢谢

回复 #3 hudeg632 的帖子