• 状态 Resolved
  • 已锁定 已锁定
  • 回复 13 回复
  • 订户 0 订户
  • 视图 653 视图
  • 用户 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.

[参考译文] CC3100：HTTP POST 事务不会间歇性完成

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1202002/cc3100-http-post-transactions-do-not-complete-intermittently

器件型号：CC3100
主题中讨论的其他器件：、 EK-TM4C1294XL、

我正在使用一个基于 CC3100的模块、该模块由 Tiva 微控制器控制、其中包含 CC3100SDK 1.3.0版、用于实现 http 服务器。

这使用与开箱即用示例类似的方案、以"NAME=__SL_P_UXX=0"格式发布消息。
大多数情况下、这会按预期运行、我可以继续使用令牌轮询程序代码来更改显示的值。

POST 事务间歇性地看起来不完整、并且在任何额外的 POST 或 GET 可以开始前有10s 超时。
使用 Chrome (110.0.5481.178)、Edge (110.0.1587.57)和 Firefox (110.0.1)时也是如此。

我更改了 javascript、以确保我只有一个公开事务与服务器、这没有区别。

我 在 user.h 文件中更改了源代码、将 MAX_CONCONVERT_OPTIONS 从10增加到32 、但这没有区别。

如果我使用 Wireshark 捕获事务、当 POST 按预期工作时、可以看到流的以下事件：

[SYN]来自浏览器
[SYN、ACK]
[ACK]  
从浏览器发帖
HTTP 204没有来自服务器的内容
[fin、ACK]来自服务器
[ACK]
[RST、ACK]

我们看到10s "超时"时后捕获如下：

[SYN]来自浏览器  
[SYN、ACK]
[ACK]  
从浏览器发帖
[来自服务器的 ACK
HTTP 204没有来自服务器的内容
[fin、ACK]
[fin、ACK]来自服务器
[ACK]从服务器
[TCP Window Update][ACK] from server
[SYN]来自浏览器的下一个流索引，它来自浏览器完成帖子时触发的 JavaScript。
[TCP Retransmission][FIN, ACK] from server
[TCP Retransmission ][SYN] from browser.

这些重新传输会重复执行、直到启动10s、然后下一个 Get 开始。

它看起来像当它工作时,服务器发送一个[ FIN, ACK]当我认为它应该严格的浏览器。
浏览器随后以[RST, ACK]结束交易。
终止事务的有效方式、可能是由意外的｛FIN、ACK]触发的。
很奇怪，但不会出问题。

当它不起作用时、似乎服务器正在等待[ACK]完成终止过程。
然而,这来自最流行的浏览器,我很难看到这是否真的是错误的。

但是、如果这是可接受的交换、则看起来 CC3100驱动程序中可能存在错误。
 但是、我无法使用搜索找到任何问题。

谢谢。

Kevin 老师

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

    故障后应用程序的状态是什么？ 您是否曾尝试过"暂停"调试器以检查程序计数器？

    您能否提供 Wireshark 日志(如果可以、使用802.11信息、例如无线监听器)？

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

    这里是 Wireshark 捕获、Kobi。 不幸的是、我没有空气嗅探器可在运行浏览器的机器外部捕获这些内容。

    e2e.ti.com/.../Error-and-good-transactions.zip

    正如您将在捕获中看到的那样、此应用程序在 http 服务器中出现10s 超时后恢复。
    虽然我目前正在使用固件的调试版本、但我发现、例如、将附加调试信息放入控制台会减慢进度、并且使重新生成故障变得更困难、这可能会导致一些时序问题。

    谢谢。

    Kevin 老师

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

    似乎我们没有收到我们发送的 TCP FIN 上的确认,因此连接保持打开(参见 FIN 数据包的重新传输),我们不接受其他 SYN 数据包(直到 FIN 超时发生)。

     MAX_CORECONVERGE_OPTIONS 在哪里定义？

    这里的用例是什么？

    似乎缺少的 ACK 符合 HTTP 服务器仅支持一个连接的限制。

    如果这是一个关键问题、您可以查找 将 在主机上运行的 HTTP 服务器软件( 在 NWP 的 TCP 套接字上运行)。

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

    谢谢、Kobi。

    我同意、当我们看到该问题时、服务器可能等待最终 ACK 以完成 TCP Connection 发布序列。
    我想知道、因为我没有从监听器或从服务器(CC3100)捕获的序列、是否会同时发送两端的 FIN、ACK 数据包、按照原样以无线方式发送、从而造成问题的间歇性。

    但是、我对 TCP 的理解有限、是只能由发送 FIN 的连接发起方(发送原始 SYN)来启动 释放序列、还是释放序列图是指要将该序列作为发起方启动的任何一端？

    我问,当我们没有看到问题时,始终是发送了 SYN 的浏览器,但发送初始 FIN 的服务器。 这也可能是浏览器在连接结束时发送 RST 的原因,而不是通过正常断开连接。

    在   安装最新 SDK 时、MAX_CONCONVERGE_OPTIONS 在 simplelink user.h 文件(移植 API 的一部分)中定义：默认情况下、该文件位于 C：\ti\CC3100SDK_1.3.0\cc3100-sdk\simplelink\templel_user.h 中。

    Kevin 老师

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

    FIN 和 SYN 之间没有关系。

    SYN 将始终由客户端(浏览器)发送。

    fin 在应用程序调用关闭时发送、这意味着该端没有其他任何要发送的内容(在套接字上)、它可以由服务器或客户端触发。

    发送 RST 可以强制断开、而无需等待另一端闭合套接字。

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

    非常感谢提供的信息、Kobi。

    那是我当时的误解,我可以忽略一个有效的通信和一个超时的通信之间的任何差异。

    浏览器(Google Chrome, Chromium Based Edge 和 Firefox )似乎尚未发送最终的 ACK。

    我接下来要做的是尝试查看另一端是否以相同的顺序看到消息。

    Kevin 老师

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

    深入研究了驱动程序代码后、似乎所有的 TCP 握手都发生在 TI CC3100 NWP 中、因此很遗憾、除非我错过了某些内容、否则我无法从 NWP 的角度来记录序列。

    令人困惑的是、当问题发生时、我们有两种方式来执行奇怪的 TCP 发布序列。

    我们看到的序列如 Wireshark 捕获中所示、是：
    1. fin、从浏览器向 CC3100发送 ACK  
    2. fin，从 CC3100 向浏览器发送 ACK
    3. 从 CC3100 向浏览器发送 ACK

    我的问题是：
    答：为什么 CC3100 在它自己的 FIN 之后发送一个 ACK？  
    B：为什么浏览器不发送 ACK 来响应来自 CC3100的 FIN、ACK？
    C： 来自 CC3100的 ACK 是否会导致浏览器看到版本完整、这就是他们不发送最终 ACK 的原因。

    谢谢。

    Kevin 老师

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

    在终止序列期间、两端都会发送一 条 FIN (在 TCP 序列号中计为1个字节)消息、并期望在消息上获取一个 ACK (否则、 它们 将重新发送 FIN 或以无格式关闭连接)。 如前所述、连接是双向的、发送 FIN 的只是告诉远程侧、我们不会在连接上发送任何内容、但 RX 路径仍将打开。 通常、发送 FIN 会 触发远程侧发送自己的 FIN、从而释放套接字。

    1.我想您的意思是对等方的 FIN 的 ACK (如果不是、请指出我们发送 ACK 的确切数据包、没有明显的原因)  

    2、我不知道。 可以丢弃数据包、但如果它是一致的(或其频率很高)、则会 出现一些问题。  

    3.是的

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

    前面随附的"Error and Good transactions.zip"中的 Wireshark 序列显示：

    No. 777、浏览器向 CC3100发送 FIN、ACK。 我认为这是发布序列的开始、浏览器是启动器。
    778号、CC3100向浏览器发送 FIN、ACK。 我相信这是对777和 FIN 从接收器。
    第779号、CC3100 向浏览器发送 ACK。

    它是第779行、我引用了该行。
    我想我们希望浏览器会有一个 ACK 来完成发布、正如您之前所说的那样、当您说"我们在我们发送的 TCP FIN 上没有得到 ACK "时、我觉得这是正确的。

    我想知道的是、为什么 CC3100当时单独发送了 ACK、是问题的根源。

    我曾尝试使用监听器捕获数据包、但目前 SimpleLink AP 必须配置为只允许单次连接。

    Kevin 老师

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

    它看起来数据包#778是在从浏览器接收 FIN (#777)之前发送的(即双方决定同时关闭连接)。

    一旦 FIN (#777)被处理、CC3100已在其上发送 ACK。

    (CC3100堆栈在2个线程中处理 RX、并在第二个线程更新#777上的 ACK 计数器之前发送 FIN+ACK (#778)的可能性也小了)。

    所以在这两种情况下、都是在没有向 FIN 本身确认的情况下发送#778数据包(ACK=582)、因此需要为 FIN 发送另一个 ACK (=583)。

    这是一个有效的序列。 问题是为什么浏览器不在我们的 FIN 上发送 ACK。  

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

    我使用 Android 手机进行了测试、使用 Chrome 时也有类似的间歇性10秒延迟。
    使用 Samsung 互联网、10s 延迟后会让 CC3100需要软复位。

    不幸的是,我没有能力捕获 TCP 通信,就像我在 Windows 11桌面计算机上一样。

    为了将该应用程序与其余应用程序分离、我将考虑创建一个可在 TI 开发套件上运行的简单应用程序、最好是 CC3100 OOBE 的一个版本。

    Kevin 老师

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

    您可以尝试获取 NWP 日志(至少对于需要软复位的问题)-请参阅 /cfs-file/__key/communityserver-discussions-components-files/968/CC3100-_2600_-CC3200-Capture-NWP-Logs-_2D00_-Texas-Instruments-Wiki.pdf.

    我不确定我们能否解决另一个问题、因为我们没有发现任何堆栈行为问题。 我想 HTTP 服务器只能与一个套接字一起工作、这无法更改(您可以在主机上使用 HTTP 服务器应用、以便在第一个套接字即将关闭时接受第二个套接字上的连接)。

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

    我使用连接 Tiva C 系列的 Launchpad (EK-TM4C1294XL)和 CC3100 BoosterPack (CC3100BOOST)构建了一个系统。

    我已经将版本1.3.0 CC3100 SDK 中的 getting_started_with_WLAN_ap、http_server 和 out_of_box 示例中的一些源代码进行了合并。

    此问题在 Win11/Chrome 中重现
    此问题在 Win11/Edge 中重现
    此问题再次出现 Win11/Firefox
    该问题不会在 Android 13/Chrome 下重现
    在 Win7/Chrome 下不会出现此问题
    此问题不在 Win10/IE11中重现

    因此，问题似乎必须与 Windows 11 TCP 内核驱动程序有关。

    因此、我已根据反馈将 ACK 标记为已解决、表明浏览器未向 CC3100 FIN/ACK 发送 ACK。

    感谢您的帮助。

    Kevin 老师