且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

MA在读取NetMon捕获时遇到了一些错误

更新时间:2022-12-07 14:25:33

对于问题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