谁搞砸了这个TCP连接?

时间:2009-06-30 15:54:13

标签: embedded tcp

我负责一些嵌入式软件,它必须与客户专有的TCP接口一起工作(也是嵌入式的,但是在一个众所周知且备受推崇的RTOS下运行),但它并没有通过三次握手,即使HTTP接口等都可以正常工作,我可以使用自定义协议与我的PC上运行的程序进行通信。

看看WireShark捕获,他的一方通过发送SYN发起,我发送一个SYN-ACK,然后他立即发送一个RST,所以看起来问题就在他的最后。我的分析是否正确?

这是问题的典型三个包示例,其中MAC ID是匿名的(真实MAC ID有效)。抱歉粘贴原始十六进制,如果有人更好地了解如何将WireShark捕获,我当然可以接受。

63  2009-06-29 13:07:49.685057  10.13.91.2  10.13.92.3  TCP 1024 > 49151 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=0 TSV=194 TSER=0

0000   f1 f1 f1 00 03 09 ab ab ab 60 10 89 08 00 45 00  
0010   00 3c 00 68 40 00 40 06 6f 35 0a 0d 5b 02 0a 0d  
0020   5c 03 04 00 bf ff 7d b3 81 44 00 00 00 00 a0 02  
0030   20 00 9c 2f 00 00 02 04 05 b4 01 03 03 00 01 01  
0040   08 0a 00 00 00 c2 00 00 00 00  

64  2009-06-29 13:07:49.685375  10.13.92.3  10.13.91.2  TCP 49151 > 1024 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0

0000   ab ab ab 60 10 89 f1 f1 f1 00 03 09 08 00 45 00  
0010   00 28 00 02 00 00 64 06 8b af 0a 0d 5c 03 0a 0d  
0020   5b 02 bf ff 04 00 d4 ff ff ff 7d b3 81 45 50 12  
0030   05 b4 47 07 00 00 00 00 00 00 00 00  

65  2009-06-29 13:07:49.685549  10.13.91.2  10.13.92.3  TCP 1024 > 49151 [RST] Seq=1 Win=0 Len=0

0000   f1 f1 f1 00 03 09 ab ab ab 60 10 89 08 00 45 00  
0010   00 28 00 6a 00 00 40 06 af 47 0a 0d 5b 02 0a 0d  
0020   5c 03 04 00 bf ff 7d b3 81 45 00 00 00 00 50 04  
0030   00 00 21 c9 00 00 00 00 00 00 00 00  

3 个答案:

答案 0 :(得分:1)

如果你们两个都在使用标准的RTOS实现,那么TCP堆栈就不太可能出现问题。或者,你说TCP是在本地实现的吗?

如果他的客户正确发送SYN,您可以使用SYN+ACK回复, 看来你的SYN+ACK形象不正确 (但是,我还没有看到任何错误),或者,
就像你怀疑的那样,他的TCP堆栈没有正确接受SYN+ACK 但是,如果这些是标准实现,则不太可能。

那么,你还能做什么?

  • 由于这是我们正在检查的TCP握手,你可以让他连接到你正在收听所需端口的任何其他机器

    • 这将检查他的实施情况(如果3方式完成则很好)。
  • 您可以通过TELNET从另一台本地计算机连接到该端口来检查您的TCP堆栈

    • 这将检查您的实施情况(如果3方式完成,则很好)。
  • 如果这些都很好,我们需要怀疑网络路径

    • 例如,是否有一些防火墙不允许通信并主动向您发送RST?

答案 1 :(得分:0)

首先,那些不是有效的MAC地址;一个高位字节& 0x1表示它是组播MAC。见http://en.wikipedia.org/wiki/MAC_address

答案 2 :(得分:0)

如果您没有像自定义tcp堆栈或原始套接字那样使用花哨的东西,我会怀疑“专有的TCP接口”。

这个曾经和那个客户合作过吗? 它与其他客户合作吗?