[参考译文] CC3120：CC3120 的 SSL 读取错误和 TCP 保持活动超时问题

您好、

TCP 通常与路由器/AP 无关、因为它们仅处理 OSI 模型中的第 3 层。

TCP 是第 4 层、因此在相互连接的两个对等设备（CC3120 和 TCP 服务器）的网络堆栈上进行处理。

TCP keepalive 用于使 TCP 连接保持活动状态并准备就绪、如果服务器在没有数据的情况下“断开“对等方、这实际上取决于服务器。

因此、您使用的服务器可能会在不到 5 分钟的时间内使对等设备启动、但这实际上是一种服务器实现方式、与路由器或 CC3120 无关。

不确定 Wi-Fi 中断的含义、它们仅用于向主机应用发出信号、表明有数据/事件待处理。

此致、

Shlomi

您好、

我们观察到、对于某些 ISP、即使在 5 分钟的 TCP 保持活动时间间隔内、我们的 TCP 连接仍保持活动状态、而对于其他 ISP、则会发生断开连接的情况。 此行为是否会受到 ISP 的影响？

此外、我们还遇到了 WiFi 芯片生成中断的问题、尝试读取数据时会收到 SSL 读取错误。 如果主机/服务器在一段时间不活动后断开连接、CC3120 是否会生成任何中断？ 我们只会在发生 AP 断开连接时收到立即中断、而不会在发生主机断开连接时收到立即中断。

非常感谢您在理解这些行为方面提供的帮助。

谢谢你。

你（们）好

我们观察到、对于某些 ISP、即使在 5 分钟的 TCP 保持活动时间间隔内、我们的 TCP 连接仍保持活动状态、而对于其他 ISP、则会发生断开连接的情况。 此行为是否会受到 ISP 的影响？

此外、我们还遇到了 WiFi 芯片生成中断的问题、尝试读取数据时会收到 SSL 读取错误。 如果主机/服务器在一段时间不活动后断开连接、CC3120 是否会生成任何中断？ 我们只会在发生 AP 断开连接时收到立即中断、而不会在发生主机断开连接时收到立即中断。

是否有任何可能导致的特定原因或配置 SSL_READ_ERROR？ 为什么此问题仅在某些互联网连接时发生、而并非在所有情况下都发生？ 对于确保稳定连接、您是否有任何建议？

非常感谢您在理解这些行为方面提供的帮助。

谢谢你。

您好、

没有  SSL_READ_ERROR 事件。 你到底得到了什么？

基本上、您应该在应用中有一个有关套接字相关错误的通用 CB、即 SimpleLinkSockEventHandler。

我不知道 ISP 如何影响 TCP 持久连接、因为它主要与 TCP 服务器本身有关、而不考虑互联网提供商。

此致、

Shlomi

嗨、Shlomi

感谢您的回答。

我们将使用 _i16 sl_Recv 所提供 link.SimpleLinkCC3120/CC3220 主机驱动程序：套接字中的函数定义。 

每当我们从该函数接收到零时、都会遇到断开问题。 您能帮助我们了解背后的可能原因吗？  

您好、

我同意 Shlomi 和他写的。

向前推进的最佳方法是通过嗅探器（如 Wireshark 或 tcpdump）捕获网络流量。 请将过滤器设置为仅捕获服务器与 CC3120 设备之间的通信。 在提供.pcap 文件之后、我们可以讨论正在发生的事情。 如果没有来自网络监听器的日志、只需猜测即可。

1 月

只需完成、在 sl_Recv () 上获得 0 就意味着另一侧关闭连接（因此在监听器上，您会看到从服务器到客户端的 TCP FIN）。

Shlomi

嗨、Shlomi。

我正在尝试嗅探数据。 在此之前、我有一些类似的问题

1. TCP 保持活动故障是如何处理的。 具体来说、我想了解 CC3120 用于检测和管理 TCP 保持活动故障的机制。 例如、在 RS9116 芯片中、TCP 保持活动故障由特定的错误代码指示、当检测到故障时、套接字将关闭。 您能否提供有关 CC3120 等效流程的详细信息、包括任何相关的错误代码、事件和建议的处理程序？

2. 此外、CC3120 上是否应配置任何特定的超时设置、以确保实现可靠的 TCP 保持活动功能？ 如果是、您能否提供有关如何配置这些设置的指导？ 因为对于 RS9116 芯片、SI 实验室告知我们使用 TCP 保持活动超时为 3 分钟、但在 CC3120 中、我们使用 5 分钟。  

您好、

您可以通过 API 对 keepalive 进行“播放“。

_i16 状态；
_u32 超时=180；/例如、每 3 分钟一次
状态= sl_SetSockOpt (SD、SL_SOL_SOLT_SOCKET、SL_SO_KeepAliveTime、(_u8*)&TIMEOUT、sizeof (timeout)；
IF（状态）
｛
//错误
}

至于 keepalive、我记得没有事件。 如果另一侧没有响应 keepalive、则很可能插座在内部关闭、但我需要检查是否是这种情况。

此致、

Shlomi

尊敬的 Shlomi：

我在断开连接期间嗅探了 Wi-Fi 数据、但没有来自服务器的 TCP FIN 或 RST。  

这通常表示路由器或 NAT 设备无提示 TCP 连接中断。 路由器由于不活动或超时而删除 TCP 会话的 NAT 映射、但不发送任何 FIN 或 RST。 如果器件认为套接字仍然有效、但在下次尝试发送数据时、TCP 协议栈会检测到故障 并触发套接字事件。 这是否是套接字触发事件的原因？  

我最初怀疑路由器会发送任何信号或触发 CC3120。 但 CC3120 的内部 TCP 协议栈仅在主机尝试使用套接字时检测到故障。 这是对连接断开的本地检测、而不是外部触发事件。 这是正确的吗？

如果在不发送任何 TCP FIN 的情况下断开 TCP 连接、则可以进行此操作。

这样、SL 不知道 TCP 连接已断开。

尊敬的 Shlomi：

如果路由器静默删除 TCP 会话的 NAT 映射（由于不活动或表耗尽）并且没有发送 TCP RST 或 FIN、那么 CC3120 的网络如何检测到此情况并做出响应、尤其是当主机 MCU 处于睡眠模式时？

您能否解释一下 SimpleLink 网络处理器在检测到传输故障时触发套接字事件的过程、以及如何将该事件传达给应用？

如果 TCP 被静默丢弃、则检测它的唯一方法是发送保持活动状态。

保持活动状态的目的是检测连接是否断开或延迟。

另一种方法是当器件正在主动发送或接收数据时。

如果它尝试接收、很可能会得到 0、这意味着另一侧不存在。

至于寄送、我不确定、因为我没有测试过。

Shlomi

尊敬的 Shlomi：

最后一个问题是、如果路由器由于不活动而删除了 TCP 会话的 NAT 映射、CC3120 是否会检测到故障并在主机 MCU 仍处于睡眠状态时触发套接字事件？

您好、

NWP 无法知道它、因为它被静默删除。

如果在任何时候发生事件而主机处于睡眠状态、则会将其唤醒、您应该会看到该事件。

Shlomi  

谢谢、  

我有一个后续问题：

如果启用了 TCP 保持活动、并且 NAT 映射以静默方式丢失、NWP 最终是否会检测到由于缺少 ACK（来自保持活动探测器）而导致的故障？

• 在这种情况下、它是否会生成套接字关闭/错误事件？
• 如果配置了套接字触发事件、这是否会唤醒主机 MCU（即使对等器件从未发送 FIN 或 RST）？

仅尝试确认仅保持活动故障是否足以触发从睡眠状态唤醒？

如果不是、当主机 MCU 处于睡眠状态时 NAT 映射丢失时、Wi-Fi 芯片发出套接字触发事件的原因是什么？  

您好、

至少从我在代码中看到,当 keepalive 耗尽所有重试次数时,套接字连接将被重置,这就像你自己关闭套接字一样。

话虽如此,我没有看到任何未经请求的事件触发主机。

因此、在这种情况下、主机在尝试从套接字接收（并且应该获得 0）或发送之前是不知道的。

此致、

Shlomi  

你（们）好  

但 TI 文档指出、在低功耗深度睡眠中、NWP 保持运行、并且可配置套接字触发以唤醒 MCU。  

此外、CC3120/CC3200 中的网络处理器处理所有非主机 MCU 的 Wi-Fi 和 TCP/IP 堆栈操作。 意味着它将处理 TCP 会话和保持活动管理。 即使主机 MCU 进入睡眠模式（如 LPDS 模式）、所有这些都将继续运行。  

具体情况如下：

1.  通过启用 NAT 的路由器建立 TCP 套接字
2. 使用 SL_SO_KEEPALIVE 启用 TCP 保持活动状态
3. 主机 MCU 低功耗深度睡眠模式
4. 一段时间后、路由器会因不活动（无 FIN 或 RST）而静默删除 NTA 映射。
5. 对等服务器不接收 Keep Alive 探测器。

我们的理解是：

1. 如果路由器出现无提示故障 、CC3120 将不知道 NAT 映射已过期、因为没有从 NAT 设备或服务器接收到明确的 TCP 层事件（如 FIN 或 RST）。
2. CC3120 仍然认为 TCP 连接处于活动状态。
3. CC3120 将继续通过其网络处理器 (NWP) 发送 TCP 保持活动探针（如果已配置）。
4. 当 NAT 映射过期时、这些保持活动探测器将无法到达服务器、因为 NAT 设备不再为连接路由数据包。
5. 如果保持活动探头没有得到应答、NWP 将在内部关闭 TCP 套接字并在套接字关闭时生成异步套接字事件。
6. 此事件可将主机 MCU 从睡眠状态唤醒、并允许处理重新连接。  
7. 这就是我手动尝试重现 TCP 会话关闭时收到套接字触发事件的方式。 当路由器关闭 TCP 会话时、MCU 仍处于睡眠模式、在 5 分钟内（即 TCP 保持活动超时）、我收到来自 Wi-Fi 芯片的套接字触发事件。   

问题：

1. 如 TI 文档和 e2e 表单中所述、NWP 在 LPDS 期间独立处理 TCP 保持活动重试是否正确？ ：https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/400040/cc3200-tcp-socket-keep-alive 
2. TI 文档： https://file.elecfans.com/web1/M00/00/06/o4YBAFnLj_GAcI77AAJsXLcKik8347.pdf?utm_source=chatgpt.com

需要对此进行确认。 所以、我会很清楚、可以结束这个问题。  

谢谢

您好、

是的、这就是它的行为方式。

NWP 处于与主机不同的功耗模式、在 NWP 因数据包而唤醒该模式之前、该模式可能会睡眠。

我没有看到、也可能错过了以下内容：在 keepalive 到期时、NWP 通过一个指示该事件的事件唤醒主机。

但据我所知、您已经进行了测试、可以看到、当 keepalive 过期时、主机在 5 分钟后处于唤醒状态。 这是真的吗？

此致、

Shlomi

是的、Shlomi。  

这是真的。 当我在 5 分钟内手动尝试从路由器端重现 TCP 会话过期时、可以看到当 TCP 保持活动过期时主机处于唤醒状态。  

这是伟大的,感谢您的验证。

因此、您的理解是正确的。

Shlomi