TI中文支持网我在软件开发过程中，一直发现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直接选择中断连接？有什么解决办法？
Tao Liu2：
由于以上图片未能正确显示，请参考下图：
Kevin Qiu1：
回复 Tao Liu2:
SDK版本是多少,用例程CC3235S_LAUNCHXL\ns\tcpecho测试过吗
Tao Liu2：
回复 Kevin Qiu1:
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问题，还请帮忙验证和告知解决方案，这样我们能尽快进入后续产品验证和量产阶段，谢谢！
Kevin Qiu1：
回复 Tao Liu2:
不清楚你的服务器是什么设备，你可以用两块CC3235S参考下面链接测试一下是否正常
dev.ti.com/…/node
Tao Liu2：
回复 Kevin Qiu1:
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有之前上述的异常情况。
Tao Liu2：
回复 Kevin Qiu1:
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有之前上述的异常情况。
Kevin Qiu1：
回复 Tao Liu2:
你可以在6.5.1.3查看TCP Keep Alive，默认time-out是5分钟www.ti.com/…/swru455m.pdf
linux端我不了解，建议你在英文论坛发帖提问e2echina.ti.com/…/
有专家帮助解答
Tao Liu2：
回复 Kevin Qiu1:
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就好了。
嗯嗯我再去英文论坛上发帖问问看，谢谢。
Kevin Qiu1：
回复 Tao Liu2:
好的
