• 状态
  • 已锁定 已锁定
  • 个回复 9 个回复
  • 名订阅用户 9 名订阅用户
  • 次查看 2317 次查看
  • 用户 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.

CC3235S作为TCP client时有时会不回复ACK给TCP server传来的keep alive心跳包

Tao Liu2
Prodigy 60 points
Other Parts Discussed in Thread: CC3235S

我在软件开发过程中，一直发现CC3235S会接收不到或不回复，TCP层server发来的keepalive包。之后为了减少变量，找到根本原因。我将CC3235S烧回了官方network terminal样例。另一端PC段，我也只开了一个TCP server。我发现此问题依旧存在！！！

测试环境：network terminal跑了 “wlanconnect -s "Amba_tliu" -t WPA2 -p "Ambarella2015" 连接我的路由器，和“recv -c 10.0.0.5 -p 8888”建立TCP连接，并block住，因为server那里不会发任何数据。TCP server段设置keepalive interval 3秒钟，retry 10次。

如下图wireshark的log, server IP: 10.0.0.5, CC3235S IP: 10.0.0.67。从log中可以看出在第218秒时，server发给TI SOC一个keepalive包，但是没有收到回复。随后，server隔3秒后再次发送一个keepalive包，此时TI SOC收到后并回复了一个TCP RST。这操作直接导致两者间的TCP连接中断！！！

我的问题是：1. 为什么TI SOC会出现收到keepalive不会ACK的情况?或者说server发了，SOC干脆没收到?  2. 为什么server已经试图retry发送keepalive了，SOC直接选择中断连接？有什么解决办法？

  • 0
    Prodigy 60 points

    由于以上图片未能正确显示，请参考下图：

  • 0 回复 Tao Liu2
    Guru 82220 points
    SDK版本是多少,用例程CC3235S_LAUNCHXL\ns\tcpecho测试过吗
  • 0 回复 Kevin Qiu
    Prodigy 60 points
    Hi Kevin, 我使用的SDK是4.30.00.06版本，样例和service pack均采用此SDK。

    对于你说的测试一下tcpecho，我看了一眼此代码，这个样例是让TI SOC做TCP server，而我遇到的情况是TI SOC作为TCP client。所以我觉得没有测试的必要吧，我之前用的官方样例network terminal测试的。

    我再详细描述一下应用背景，我们的project中TI 设备是TCP client需要TCP 长连接我们的server。期间如果TCP没有信息通讯，我们server会间隔固定时间向TCP client段发送keepalive信息。这是TCP/IP协议中自带的功能，并非我们APP层实现的keepalive心跳包。

    我遇到的问题是，在保持TCP长连接过程中，TI设备经常会异常不回复server发过来的keepalive包。之后，在server没收到第一个ACK后，再一次发送keepalive包后，TI设备会回复一个TCP RST包给server，导致长连接break掉了。此问题非常容易复现，在我本地5分钟-4个小时必定会出现一次。

    另外我有交叉验证过另一款broadcom的SDIO wifi，该芯片无论在sleep模式还是工作模式均能正确处理server传来的keepalive包，所以我相信不是我们server问题，同时从wireshark的log也能看出是因为TI设备未能正确回复ACK和额外回复RST信息导致TCP长连接断开。

    我们项目目前用CC3235已开发到最后阶段，目前遇到这个critical问题，还请帮忙验证和告知解决方案，这样我们能尽快进入后续产品验证和量产阶段，谢谢！
  • 0 回复 Tao Liu2
    Guru 82220 points
    不清楚你的服务器是什么设备，你可以用两块CC3235S参考下面链接测试一下是否正常
    dev.ti.com/.../node
  • 0 回复 Kevin Qiu
    Prodigy 60 points
    Kevin, 我的服务器是Linux PC。TCP connection是正常的，我server与TI SOC间socket的收发数据都是okay。我们application都开发到最后阶段了，这TCP socket的数据传输都没有问题。我遇到的问题是TCP/IP层的keepalive包的问题。这不是我们application层handle的，在网络协议TCP/IP层机制里自行handle。我们在最后挂机长跑时候遇到的问题，期间server与TI SOC之间是没有数据传输的，TCP/IP层后台会用keepalive机制来保持TCP connection的长连接，在这过程中发现CC3235有之前上述的异常情况。
  • 0 回复 Kevin Qiu
    Prodigy 60 points
    Kevin, 我的服务器是Linux PC。TCP connection是正常的，我server与TI SOC间socket的收发数据都是okay。我们application都开发到最后阶段了，这TCP socket的数据传输都没有问题。我遇到的问题是TCP/IP层的keepalive包的问题。这不是我们application层handle的，在网络协议TCP/IP层机制里自行handle。我们在最后挂机长跑时候遇到的问题，期间server与TI SOC之间是没有数据传输的，TCP/IP层后台会用keepalive机制来保持TCP connection的长连接，在这过程中发现CC3235有之前上述的异常情况。
  • 0 回复 Tao Liu2
    Guru 82220 points
    你可以在6.5.1.3查看TCP Keep Alive，默认time-out是5分钟www.ti.com/.../swru455m.pdf
    linux端我不了解，建议你在英文论坛发帖提问e2echina.ti.com/.../
    有专家帮助解答
  • 0 回复 Kevin Qiu
    Prodigy 60 points
    Kevin, 你说的这个文档我之前也有读过。keepalive的设定是在server端设置的。所以当TI SOC作为TCP server时，才需要考虑设置keepalive time-out。设置后，当TCP connection没有数据通信后，每间隔5分钟会向client发一个keepalive包。

    我的应用还是将TI设备作为TCP client，所以它是接收keepalive包，并不需要设置这个TCP keepalive在TI设备上的。所以TI设备不用管我什么时候发给它keepalive包，只需要管收到后回我个ACK就好了。

    嗯嗯我再去英文论坛上发帖问问看，谢谢。