MA在读取NetMon捕获时遇到了一些错误 [英] MA is hitting some errors when it reads a capture taken with NetMon

问题描述

AFAIK NetMon采取的捕获有效且有253帧。 

问题1

MA 报告应用程序警告TCP：段丢失，丢失3次握手@消息251

NetMon帧251

251  3：17：13 PM 5/2 /2013 30.1412253 TCP TCP:[Keep alive ack] Flags = ... A ....，SrcPort = Microsoft-DS（445），DstPort = 58349，PayloadLen = 0，Seq = 3477487611，Ack = 3559020834 ，Win = 513  {TCP：30，IPv4：29}

期望 - 不确定，我想NetMon可能会丢掉一些东西。

问题2

MA显示最后两条消息，消息＃117& ＃128其报告"InsufficientData \tHTTP：由于缺少连续消息而导致完全重组的HTTP有效负载不完整。解析\t无法完全解析消息。在解析器收集足够的信息以继续解析之前，跟踪结束了
。"

扩展消息＃117，MA显示一系列消息都具有src端口58359

扩展消息＃128，MA显示一系列消息都有src prot 80

我希望解析工作并按照时间顺序列出消息交错请求/响应。 

解决方案

对于问题1，我们显示诊断当我们看到一条缺少原始三次握手的TCP消息时。 我的想法是提醒您，以便您了解协商的TCP选项丢失，这意味着窗口大小计算和其他
的事情可能不准确。

对于问题2，它是很难说没有看到数据，但看起来好像我们在显示消息之前等待整个TCP有效负载完成。  Message Analyzer的一个主要区别是我们进行模拟和自动重组。 
这意味着您看到消息的默认顺序是模拟吐出的顺序。 在这种情况下，我们从未收到过所有数据，因为在我们决定不再有消息要处理之前我们不会显示消息。
的另一个区别是，当有效负载未完成时，它们可能无法显示。 因此，在网络监视器中显示为HTTP的流量可能根本不会显示在消息分析器中。

谢谢，

保罗

AFAIK the capture taken by NetMon is valid and has 253 frames. 

Issue 1

MA reports Application Warning TCP:segment lost, missing 3-way handshake @ message 251

NetMon frame 251 has

251 3:17:13 PM 5/2/2013 30.1412253 TCP TCP:[Keep alive ack]Flags=...A...., SrcPort=Microsoft-DS(445), DstPort=58349, PayloadLen=0, Seq=3477487611, Ack=3559020834, Win=513 {TCP:30, IPv4:29}

Expectation - not sure, I suppose NetMon could have dropped something.

Issue 2

MA shows the last two messages, message # 117 & #128 where it reports "InsufficientData\tHTTP: Incomplete HTTP payload for full reassembly, due to missing contiguous messages. Parsing\tThe message could not be parsed completely. The trace ended before the parser collected enough information to continue parsing."

expanding message #117, MA shows a series of messages all having src port 58359

expanding message #128, MA shows a series of messages all having src prot 80

I expected the parsing to work and have the messages listed in the chronologic order with interleaved requests/responses. 

解决方案

For issue 1, we display a diagnosis when we see a TCP message that is missing the original three way handshake.  The idea is to alert you so you understand that negotiated TCP options are missing which means that Window size calculation and other things might not be accurate.

For issue 2, it's hard to say without seeing the data, however it looks as though we were waiting for the entire TCP payload to complete before showing the message.  A major difference for Message Analyzer is that we do simulation and automatic reassembly.  This means the default order you see the messages are the order in which the simulation spits them out.  In this case we never received all the data, there for we don't show the message until we decide no more messages are there to process. Another difference is that when payloads are not complete, they might not display.  So traffic that shows as HTTP in Network Monitor might not display at all in Message Analyzer.

Thanks,

Paul

这篇关于MA在读取NetMon捕获时遇到了一些错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！