查看: 13962|回复: 29

各位大虾,请问loops on same request 是什么错误?

[复制链接]
发表于 2008-10-17 17:22:45 | 显示全部楼层 |阅读模式
各位大虾,请问loops on same request 是什么错误?是什么情况造成的?谢谢!
回复

使用道具 举报

发表于 2008-10-17 23:06:24 | 显示全部楼层
回复

使用道具 举报

 楼主| 发表于 2008-10-18 00:58:12 | 显示全部楼层

回复 2# 的帖子

谢谢oldjiang大哥!可是还是不是很明白,由于数据的特殊性不方便把cap传上来,截一下图,请大家再帮忙分析一下!另外还有几个疑问:
1 XWIN Continuration of frame xxxx 是什么东东,是因为使用了6000端口的原因吗?
2 我只发送了长度是1163字节的数据,为什么会出现很多长度是2326的数据包?是我的两个数据之间的时间间隔太小了吗?

[ 本帖最后由 gqcgh 于 2008-10-18 16:45 编辑 ]
sniffer.JPG
回复

使用道具 举报

发表于 2008-10-18 01:24:40 | 显示全部楼层
sniffer我不熟悉
科来可以打开sniffer的数据包,看看科来有何判断
1163×2=2326,参考http://www.csna.cn/forum.php?mod=viewthread&tid=9996 网络中的超大帧
回复

使用道具 举报

 楼主| 发表于 2008-10-18 01:54:42 | 显示全部楼层

回复 4# 的帖子

呵呵,还没睡呢,oldjiang大哥,多谢啦! 我去学习学习!
回复

使用道具 举报

 楼主| 发表于 2008-10-18 16:43:44 | 显示全部楼层
看了网络超大帧的资料,感觉我的这个问题不像是这个原因,因为每一IP包的标识都是不一样的,附图是科来的分析,同时又发现了几个问题,希望各位继续帮忙解答,谢谢!
(1)为何会出现校验和错误?
(2)为什么确认包的长度都是68,感觉长度应该是64才对啊?!
(3)192.168.8.120发送数据的时候,所携带的确认号都是一个值,这个有没有问题,是120的问题,还是91的问题?
同时也有必要说一下我抓包的位置,我是直接在120的PC机上抓到的,暂时不好从其他位置抓取!

[ 本帖最后由 gqcgh 于 2008-10-19 16:34 编辑 ]
科来分析.JPG
回复

使用道具 举报

 楼主| 发表于 2008-10-19 16:37:06 | 显示全部楼层
。。。。。。。。。。。
回复

使用道具 举报

发表于 2008-10-19 21:45:43 | 显示全部楼层

回复 6# 的帖子

1、校验和错误,参考http://www.csna.cn/forum.php?mod=viewthread&tid=9234
2、确认包的长度都是68,也许有TCP选项或者额外数据,看看数据包的解码
3、确认号都是一个值,这个是正常的,因为对方没有给他发送数据,即对方的序列号没有变。参考http://www.csna.cn/forum.php?mod=viewthread&tid=2218 TCP序列号和确认号详解
回复

使用道具 举报

 楼主| 发表于 2008-10-20 12:20:59 | 显示全部楼层

回复 8# 的帖子

十分感谢oldjiang大哥的解答!校验和错误和确认号的问题已经理解了!剩下的问题再整理一下,希望各位大虾继续多多帮助!
1  loops on same request 到底是什么错误?在sniffer中它是一个警报,在科来却找不到。
2  “超大侦"的问题是不是数据发送过快造成的?会不会出什么问题,比如说大包被对方丢弃?
3 6000端口可不可以作为普通的通讯用?
4 回应长度是68的问题,科来分析的结果是没有错误的,但是很奇怪抓的其他包的回应都是64啊,大家可以看附图。另外一个问题是相同的情况,对比这两个回应包,不同的还有DF位的值,这个值到底是怎么设置的,反映的是本机的情况还是对方的情况?现在的情况是120同88通讯是正常的,但是91老是报警(没有收到数据或数据错误?)

[ 本帖最后由 gqcgh 于 2008-10-20 12:24 编辑 ]
68bytes.JPG
64bytes.JPG
回复

使用道具 举报

发表于 2008-10-20 14:08:33 | 显示全部楼层
一般一个应用在一定时间内多次重复发送同一个应用请求被认为是loops on same request。这在Xwin协议中是正常的,不断请求鼠标的位置。

Loops on Same Request
The Expert generates the Loops on Same Request alarm when it sees the application process on one station send out the same request even though it has already received the appropriate reply from the destination station. Only requests that are sent within the time specified by the Filter time threshold are considered "repeated."

Possible causes:
This may be legitimate, depending upon the application. For example, some print servers check for print requests every few seconds, resulting in many repetitions of the same request. You can eliminate this situation by lowering the Filter time threshold.
Particular applications may be inefficient. For example, some X Windows applications continually check the location of the mouse cursor, which can cause network traffic of this type.
Excessive repeated requests are characteristic of applications that do not use the network efficiently, or that are not designed to be used over networks.
If the request is a Novell NDS verb request, it may indicate the need to partition the NDS tree among more servers. However, the verbs DSV_Resolve_Name, DSV_Read, and DSV_Get_Server_Address are often sent out as part of the NDS protocol
回复

使用道具 举报

 楼主| 发表于 2008-10-20 16:14:26 | 显示全部楼层

回复 10# 的帖子

谢谢gu_chong的解答,也接受您的说明!可问题是现在使用的并不是Xwin协议,仅仅是普通的TCP协议,数据解码是从哪里知道的是Xwin协议?仅仅是6000这个端口吗?那可不可以说在使用6000这个端口做普通的通讯的时候出现上述的警报是sniffer的虚警?有知道的朋友,请多多指教!
回复

使用道具 举报

发表于 2008-10-20 16:20:55 | 显示全部楼层
"多次重复发送同一个应用请求",是否就是科来诊断传输层的“TCP重传数据包”、“TCP快速重传数据包”、“TCP太多重传”?
回复

使用道具 举报

发表于 2008-10-21 12:58:12 | 显示全部楼层
把捕获文件发上来看看,把你想分析什么说说。

  "多次重复发送同一个应用请求",是否就是科来诊断传输层的“TCP重传数据包”、“TCP快速重传数据包”、“TCP太多重传”?
    不同层面的,一个是应用层,一个是传输层,TCP重传数据包一般是由网络丢包引起的

评分

1

查看全部评分

回复

使用道具 举报

 楼主| 发表于 2008-10-22 09:30:02 | 显示全部楼层

回复 13# 的帖子

捕获的数据抓图在楼上有几个,想分析的问题简单说是:IP为91的设备报警数据有问题,从抓包数据能否看出异常。上边具体的问题是“感觉”异常的地方,请各位继续指教!

[ 本帖最后由 gqcgh 于 2008-10-22 09:31 编辑 ]
回复

使用道具 举报

发表于 2010-8-20 15:43:19 | 显示全部楼层
怎么老是老贴啊,都好几年的了!!!!!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | CSNA会员注册

本版积分规则

快速回复 返回顶部 返回列表