谁在搞乱这个 TCP 连接？答案

【问题标题】：Who's Messing Up this TCP Connection?谁在搞乱这个 TCP 连接？
【发布时间】：2009-07-01 00:30:36
【问题描述】：

我负责一些必须与客户的专有 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

【问题讨论】：

您可以将 WireShark 捕获文件放在某个 Web 服务器上供我们下载。

标签： embedded tcp

【解决方案1】：

如果你们都使用标准 RTOS 实现，则 TCP 堆栈不太可能有问题。或者，你说 TCP 是本地实现的？

如果他的客户正确发送SYN，您可以回复SYN+ACK，
看来您的 SYN+ACK 格式不正确
（但是，我还看不出有什么问题），或者，
就像您怀疑的那样，他的 TCP 堆栈没有正确接受 SYN+ACK。
但是，如果这些是标准实现，那是不太可能的。

那么，你还能做什么？

由于我们正在检查 TCP 握手，您可以让他连接到您端的任何其他正在侦听所需端口的机器
- 这将检查他的实现（如果 3-way 完成则很好）。
您可以使用TELNET 从另一台本地计算机连接到端口来检查您的 TCP 堆栈
- 这将检查您的实现（如果 3-way 完成则很好）。
如果这两个都没有问题，我们需要怀疑网络路径
- 例如，是否有防火墙不允许通信并主动向您发送 RST？

【讨论】：

我这边是一个没有 RTOS 的“裸机”设备，但我们正在使用一个已经存在一段时间的开源 TCP 堆栈，就像我说的，它可以与其他机器和其他机器一起使用协议，只是这台机器没有这个协议。我刚刚用 telnet 连接到我的设备，它工作正常。网络中应该没有什么东西在困扰我们——他和我之间唯一的东西是一台带有两个网卡桥接的 Windows PC，因此我们可以使用它来嗅探流量，这不会给我们带来任何其他设备的问题。我会考虑编写一个基于 PC 的协议实现供他测试。
好吧，如果 TCP 3 次握手对他不起作用，他离协议测试还很远。你应该只为他在某些 PC 上的预期协议端口上运行 TELNET 服务器。或者，也许从某个地方获取一个 TCP ECHO 服务器样本并将其安装在 PC 上所需的端口。
在 PC 上编写协议的实现，例如使用.NET TCP 套接字 API 将允许他测试他的连接以及测试协议。对他来说，深入了解他的设备更加困难——他没有为他的设备开发固件，他只是使用专有语言编写在其上运行的应用程序。这意味着我必须想尽一切办法利用我有限的能力来改变/消除这个谜题中的变量。
一旦你达到协议测试级别，这是一个不错的选择。但是，当您为他进行模拟时，不要阻止他用更简单的东西调试这个 3-way。
只是一个想法：您对裸机上的开源堆栈的描述听起来很像 PIC 上的微芯片 tcp/ip 堆栈。如果是这种情况，堆栈，尤其是旧版本会出现这种类型的一些问题。如果是这种情况，请查看 www.microchip.com 上的 TCP/IP 论坛以确定它是否是相关问题。

【解决方案2】：

首先，这些不是有效的 MAC 地址；高位字节 & 0x1 表示它是多播 MAC。见http://en.wikipedia.org/wiki/MAC_address

【讨论】：

我怀疑 sskuce 已经清理了 MAC
在嵌入式环境中，我认为他可能是任意选择了导致他出现问题的“随机”MAC。至少，这里发生了这种情况，并导致了组成 MAC 中的高位字节应为 0 的规则:)
糟糕，我确实忘记提到我已经清理了 MAC。双方都有自己的 OUI，所以我不希望它们被识别出来。

【解决方案3】：

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

这曾经与那个客户合作过吗？它是否适用于其他客户？

【讨论】：

我正在运行一个运行良好的网络服务器，至少在我尝试过的所有浏览器以及一些直接与端口 80 通信的 .NET 程序上都可以。