• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 10 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 161 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC3100MODBOOST：未捕获 TCP 上一个序列并重复确认

admin
Guru**** 1826070 points
Other Parts Discussed in Thread: TMS570LS0432, CC3100
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/715527/cc3100modboost-tcp-previous-sequence-not-captured-and-duplicate-acknowledge

器件型号：CC3100MODBOOST
主题中讨论的其他器件：TMS570LS0432、 CC3100

您好！

我将 CC3100模块用作接入点和 TCP 服务器。 我的 PC 连接到接入点的 WLAN。 然后、我的 PC 上的程序连接到 CC3100的服务器、服务器开始使用 TCP 数据包传输数据。 我的目标是使用 TMS570LS0432微控制器收集 CAN 总线消息、并通过 CC3100将其发送到具有 TCP 协议的 PC。 目前、我每秒发送大约1500个 TCP 数据包(每个 CAN 总线消息(14个数据字节) 1个 TCP 数据包(总共68个字节))。 只有从 CC3100服务器到 PC 客户端的数据传输。 在 CC3100向 PC 发送"TCP 上一个段未捕获"数据包之前、我的传输工作正常(请参阅我的 Wireshark 捕获文件、标记为数据包编号) 50914)。 然后是从我的 PC 发送的大量"TCP DUP ACK"消息。 CC3100随后进行了一些重新传输、并且所有发送的数据均已正确接收。 但是、这种行为会导致很多延迟、因此我的控制器上 CAN 消息缓冲区已满、我丢失了一些 CAN 消息。 在该主题中描述了相同的问题，但没有人发布解决方案。 那么、有人能告诉我这种行为的原因是什么？ 为什么 CC3100会发送一条"未捕获数据包"消息、以及为什么 PC 会发送如此多的"DUP ACK"消息？

此致
米歇尔

e2e.ti.com/.../WiresharkCaptureFile.zip

  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    很抱歉、我犯了这个错误、因为我过滤了 Wireshark 捕获文件中的 Windows 流量、"TCP Previous Segment not captured"数据包不能 50870。
  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Michel、

    请验证您是否收到任何 sl_Send 调用的 sl_socket_TX_failed_event。 此外、要缩小问题范围、请尝试使用 iperf 接收(这在 CC3100 SDK 的 TCP 套接字示例 中使用：processors.wiki.ti.com/.../CC3100_TCP_Socket_Application)

    "TCP Previous Segment not captured"是 Wireshark 生成的消息(不是由 CC3100发送)： documentation.help/.../ChAdvTCPAnalysis.html 。


    此致、
    Toby

  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Toby：

    调用 sl_Send()时，我的程序中没有任何错误，所有数据都已正确发送。 唯一的问题是由奇怪的行为导致的延迟。 我刚刚使用 iPerf 测试了我的程序。 作为客户端连接到 iPerf 服务器的 CC3100器件正确发送数据。 请参阅此 iPerf 日志和 Wireshark 捕获文件"iPerf Server.pcapng"(开始时仅进行一次重新传输)。 

    C:\Users\miche>"C：\Portable \iPerf 2.0.9 Win 64\iperf.exe"-s -p 5001 -i 1
-------------------------------------------------------
在 TCP 端口5001
上侦听服务器 TCP 窗口大小：208KB (默认值)-------------------------------------------------------

[4]本地192.168.1.2端口5001与192.168.1.1端口62630
[ID]间隔相连 传输 带宽
[4] 0.0 - 1.0秒176 KB 1.44 Mbits/sec
[4] 1.0 - 2.0秒172 KB 1.41 Mbits/sec
[4] 2.0 - 3.0秒175 KB 1.43 Mbits/sec
[4] 3.0 - 4.0 174 KB 1.42 Mbits/sec
[4] 4.0 - 5.0秒174 KB1.42 Mbits/sec [4] 4.0 - 5.0秒174 KB 1.42 Mbits/sec
[4] 6.0 - 5.0 SEC 175 KBytes 1.43 Mbit/s
[4] 6.0-7.0 sec 172 KBytes 1.41 Mbits/sec
[4] 0.0- 7.9 sec 1.34 MBytes 1.43 Mbits/sec

    但是、在服务器模式下使用器件分别接收器件数据时、似乎会出现问题、因为 Wireshark 会将许多 TCP 数据包标记为"TCP Window full"、"TCP ZeroWindow"和"TCP ZeroWindowProbe"。 在我可以分析的方面(我不是 Wireshark 专家)、PC 发送数据的速度太快、CC3100器件会尝试告诉 iPerf 停止发送数据、直到它将接收缓冲区降为零、连接中断。 但我认为这目前不是我的问题(我对吗？)。 有关 Wireshark 日志文件、请参阅"iPerf Client.pcapng"、这是客户端模式下 iPerf 的 iPerf 日志： 

    C:\Users\miche>"C：\Portable \iPerf 2.0.9 Win 64\iperf.exe"-c 192.168.1.1 -p 5001 -i 1
-------------------------------------------------------
连接到192.168.1.1的客户端，TCP 端口5001
TCP 窗口大小：208 KB (默认值)
-------------------------------------------------------
[3]本地192.168.1.2端口26171与192.168.1.1端口5001
[ID]间隔相连 传输 带宽
[3] 0.0- 1.0秒512 KB 4.19 Mbit/s
[3] 1.0- 2.0秒128 KB 1.05 Mbits/sec
[3] 2.0- 3.0秒256 KB Mbits/sec
[3] 3.0- 4.0秒128 KB 1.05 Mbits/sec
[3] 4.0- 5.0秒128 KB 1.05 Mbits/sec [3] 3.0- 5.0
SEC 256 KB 2.10 Mbit/s
[3] 6.0 - 7.0 sec 128 KB 1.05 Mbit/s
写入失败：管道断裂
[3] 0.0 - 17.9 sec 1.50 MB 704 kbits /秒

    由于 Wireshark (iPerf 客户端和 iPerf 服务器)没有标记为"TCP DUP ACK"的消息、导致延迟、并且 CC3100设备正确发送数据、 我希望我的程序没有问题。

    以下是两个 Wireshark 日志文件、一个用于服务器模式下的 iPerf、一个用于客户端模式下的 iPerf。

    e2e.ti.com/.../Wireshark-Capture-Files.zip

    我希望这些附加信息有助于解决该问题。

    此致
    米歇尔

    PS：Sorrrey 的答复较晚，其间有一个周末。

  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    根据我的理解、您已评估了以下案例：
    -(CC3100、AP 模式、TCP 客户端)---- >(iperf、TCP 服务器) 工作正常
    -(CC3100、AP 模式、TCP 服务器)<---- (Iperf、TCP 客户端) 窗口已满等

    还请尝试以下案例(我认为这与您的用例相匹配？) ：
    -(CC3100、AP、TCP 服务器)--- >(iperf、TCP 客户端)
  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Toby：

    感谢你的答复。 您说得对、我没有测试我的用例。 我已经知道了这一点、但在 iPerf 2中、服务器始终是接收器、客户端始终是发送器(我不知道在 iPerf 2中如何更改)。 尽管如此，我更改了程序代码以在服务器模式下发送数据，并尝试使用此命令启动 iPerf 2客户机" -c 192.168.1.1 -p 5001 -i 1"。 但是、iPerf 客户端和 CC3100服务器都尝试发送数据、我再次收到这些"窗口已满"和"零窗口"消息。 然后、iPerf 输出如下： 

    C:\Users\miche>"C：\Portable \iPerf 2.0.9 Win 64\iperf.exe"-c 192.168.1.1 -p 5001 -i 1
-------------------------------------------------------
连接到192.168.1.1的客户端，TCP 端口5001
TCP 窗口大小：208 KB (默认值)
-------------------------------------------------------
[3]本地192.168.1.2端口27871与192.168.1.1端口5001相连

    在使用 CTRL + C 一分钟后取消 iPerf 时、由于没有更多的输出、控制台会显示这种情况： 

    写入失败：按对等
[ ID]间隔重置连接 传输 带宽
[3] 0.0-80.6秒256KB 26.0 Kbits/sec

    所以我肯定认为这是错误的方法。 我找到了一个替代方案。

    在 iPerf 3中、您可以使用"-R"参数以反向模式运行 iPerf (服务器发送、客户端接收、请参阅 https://iperf.fr/iperf-doc.php)。 因此我尝试使用 iPerf 3并执行以下命令：" -c 192.168.1.1 -p 5001 -i 1 -R”。 但是 iPerf 3似乎与我的程序代码或 CC3100不兼容、因为它抛出以下错误消息： 

    C：\Users\miche>"C：\Portable \iPerf 3.1.3 Win 64\iperf3.exe"-c 192.168.1.1 -p 5001 -i 1 -R
iperf3：错误-收到未知的控制消息

    我无法通过 Wireshark 捕获文件得知为什么 iPerf 3生成此消息。 以下是我的 Wireshark 捕获文件、如果它们对任何人都有帮助： e2e.ti.com/.../4762.Wireshark-capture-files.zip

    如果我远离当前分析并从"TCP 视图"查看我的问题分析、则在建立连接后、服务器和客户端之间应该没有区别、因为它完全对称(服务器和客户端都可以发送和接收数据)。 正如我们看到的、配置 CC3100发送数据和 PC/iPerf 接收数据(无论谁是客户端或服务器)在我的测试中工作正常。 因此、在努力处理由于不兼容或其他原因导致的 iPerf 3错误消息之前、我会寻找另一种解决问题的方法。

    我可以尝试的下一件事是发送更少的 TCP 数据包、数据包的有效负载更大。 我认为每秒超过1500个数据包、且只有14字节的有效负载、但总共68字节的流量相当多。 因此、我只能每10ms 发送一个数据包。 这将是每秒最多100个数据包和大约210字节有效载荷(15 x 14字节消息)以及总共约264字节(如果数据包开销相同)。 可能是因为"在线"减少了 Trafic (816kbit/s 与211,2kbit/s)、并且需要应答的数据包较少、因此重新传输不会导致太多延迟。

    无论如何、我对本主题感兴趣、一般而言、CC3100或 TCP 协议是否不能用于传输大量单个小消息？ 我希望 TCP 能正确处理它。 我希望传输大量的小消息、因为传输的数据会传递到实时显示。 如果传输的大消息为1400字节、则会导致"显示 stuttering"(或您可以用英语调用的任何内容)。 因此、每当接收到新的大数据包时、屏幕都会更新 (这将是每秒一次)。 但我想您看不到10ms 的延迟。

    我希望我能对这些补充信息有所帮助。 如果我已经测试了我的想法、我很快就会回复。 如果您对如何修复 CC3100的奇怪行为或如何避免 iPerf 3错误消息有任何进一步的想法、请告诉我。 我感谢大家的回答。

    此致
    米歇尔

  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    一般而言、发送更长而不是更短的 TCP 数据包更好(由于您提到的开销)。

    iperf 检查的目的是验证 PC 应用程序不是限制因素(例如、需要更多时间处理接收到的数据包)。 现在您已经提到了一个屏幕、需要记住的另一点是、通常60Hz (~16ms)刷新率就足够了。 您目前每~0.7ms 发送一次、因此您在设置数据包大小方面具有很大的灵活性。

    关于 CC3100作为服务器发送、您可能可以尝试使用简单的 python 客户端从 CC3100服务器接收数据、并查看 Wireshark 捕获中是否看到类似结果： 

    导入套接字


tcp_ip ='192.168.1.1'
tcp_port = 5001
buffer_size = 1024s

= socket.socket (socket.AF_iNet、sock_stream)
s.connect (((tcp_IP、tcp_port))

、同时(1)：
数据= s.recv (buffer_size)
#print "received data："、data #print if needed

s.close()

    如果您看到类似的结果、则可以将焦点缩小到 CC3100 (而不是您的 PC 应用)。

    此外、对于您 之前使用的 iperf 配置(CC3100客户端发送到 iperf 服务器)、请尝试接收超过7.9秒的数据、因为在原始 Wireshark 捕获中、"TCP Previous Segment not captured"出现在~26秒。

  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Toby：

    感谢您的回答。 同时、我已经测试了发送更少的 TCP 数据包和更多的有效负载。 现在、即使在更高的传输速率下、数据传输也能完美地工作。 这似乎是一个有效的解决方案。

    由于我仍然对"TCP prevois segment not captured"消息感兴趣、因此我已编写了一个小客户端接收程序、用于将 CC3100测试为发送数据的服务器。 由于我不熟悉 Python、因此我使用了 Java、而是使用了以下代码： 

    导入 java.net.Socket;

公共静态空 main2 (String[] args)抛出异常｛

套接字=新套接字("192.168.1.1"、5001)；

if (！socket.isconnected())｛
return；
｝

while (true)｛
int i = socket.getInputStream()；
｝

    传输大量的小型 TCP 数据包时、我会得到与以前相同的行为(大量"TCP DUP ACK"等)。 如果我每隔10ms 发送一次具有更多有效载荷的消息、就没有问题了。 因此、我认为 CC3100无法接受许多 TCP 确认消息(我不认为我的 PC 对于微控制器或 CC3100来说太慢、并且 Java 应用程序的接收缓冲区大约为65000字节)。 要么无法使用 CC3100发送大量小型 TCP 数据包(由于硬件或其他方面的限制)、要么我的软件或 CC3100的程序中存在软件故障。 但是、我只是在将 CC3100设置为接入点模式后与 CC3100建立连接、然后使用 sl_Send（)向客户端发送数据、如下所示： 

    _i16 status = sl_Send (socketID、数据、长度、0)；
if (status <= 0)｛
printInt ("[TCP Server]数据发送错误：%d\r\n"、状态)；
status = sl_close (socketID)；
返回 tcp_send_error；
｝

    如果可能的话、我没有配置任何 TCP 传输参数。 现在、我认为通过发送越来越少、越来越大的 TCP 数据包可以解决我的问题。 但是、如果您能告诉我为什么即使在使用较低数据速率的情况下、它也不能处理较小的 TCP 数据包、我想知道这种情况的原因。

    感谢您的支持。

    此致
    米歇尔

  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我忘记附加使用上述代码录制的 Wireshark 捕获文件。 如果 CC3100出现问题、则可能有助于进行问题分析。

    e2e.ti.com/.../Java-TCP-client-receiving-data.zip

  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    这可能是由于 CC3100同时用作 AP。 如果您的应用不一定要求 CC3100成为 AP、也许您可以尝试将 CC3100连接到外部 AP、将 PC 连接到同一 AP、然后检查您是否看到类似的结果。

    很高兴您的项目处于工作状态。 希望您不会遇到太多"显示 stutting "。
  • 0
    TI__Guru**** 1826070 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Toby：

    由于我的 CC3100被放置在赛车中用于遥测、而且我不希望外部路由器作为接入点、因此我认为我的当前设置是最好的。 由于大多数笔记本电脑都没有接入点模式、因此电路太多会在基站模式下使用 CC3100。 顺便说一下、我认为这不是因为接入点模式会使 CC3100负担过重(没有其他客户端连接)、而是 TCP 确认数据包的负载。

    感谢您立即获得有效的解决方案！

    此致
    米歇尔