谁搞乱了这个 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
I'm responsible for some embedded software that has to work with a customer's proprietary TCP interface (also embedded, but running under a well known and well regarded RTOS), but it's not getting through the three-way handshake, even though the HTTP interface, etc., all work fine, and I can communicate using the custom protocol with a program running on my PC.
Looking at the WireShark captures, his side initiates by sending a SYN, I send a SYN-ACK, and then he immediately sends a RST, so it looks like the problem is on his end. Is my analysis correct?
Here's a typical three packet example of the problem, with the MAC IDs anonymized (the real MAC IDs are valid). Sorry about pasting the raw hex, if anybody's got a better idea of how to put the WireShark capture up, I'm certainly amenable.
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果你们都使用标准 RTOS 实现，则 TCP 堆栈不太可能出现问题。 或者，你说TCP是本地实现的？
如果他的客户端正确发送
SYN，并且您可以回复SYN+ACK，看来您的
SYN+ACK格式不正确（但是，我还没有发现任何问题），或者，
正如您所怀疑的，他的 TCP 堆栈没有正确接受
SYN+ACK。然而，如果这些是标准实现，那就不太可能了。
那么，你还能做什么呢？
由于我们正在检查的是 TCP 握手，因此您可以让他连接到您端正在侦听所需端口的任何其他计算机
您可以通过从另一台本地计算机连接到端口的
TELNET检查 TCP 堆栈如果这两件事都很好，我们需要怀疑网络路径
If both of you are using standard RTOS implementations, it is unlikely the TCP stack has a problem. Or, did you say the TCP is locally implemented?
If his client sends a
SYNproperly, and you can reply with aSYN+ACK,it would appear that either your
SYN+ACKis not well formed(but, I could not see anything wrong yet), or,
like you suspect, his TCP stack did not accept the
SYN+ACKproperly.However, if these are standard implementations, that is unlikely.
So, what more can you do?
Since it is the TCP handshake we are checking, you can just make him connect to any other machine at your end that is listening on the desired port
You can check your TCP stack with a
TELNETconnect to the port from another local machineIf both these things are fine, we need to suspect the network path
首先，这些不是有效的 MAC 地址； 高位字节和 0x1 表示它是多播 MAC。 请参阅http://en.wikipedia.org/wiki/MAC_address
First of all, those aren't valid MAC addresses; a high-order byte & 0x1 means it's a multicast MAC. See http://en.wikipedia.org/wiki/MAC_address
如果您没有使用自定义 TCP 堆栈或原始套接字等奇特的东西，我会怀疑“专有 TCP 接口”。
这与该客户合作过吗？
它可以与其他客户一起使用吗？
If you're not using fancy stuff on your side like custom tcp stack or raw sockets, I'd suspect the "proprietary TCP interface".
Has this ever worked with that client?
Does it work with other clients?