[求助]一个有关LWIP的问题。

我在LPC2460平台，使用8019做了一个TCP服务程序。该进程接收从PC传来的自定义数据包。每个数据包包含包头和校验信息。服务进程计算包的数据是否与校验相同，然后向PC机返回正确与否的结果。进行大数据量测试时，发现有时TCP连接会断开。打开LWIP的调试信息，发现出错信息如下：
else if (pcb->nrtx == TCP_MAXRTX) {
++pcb_remove;
LWIP_DEBUGF(TCP_DEBUG, (“tcp_slowtmr: max DATA retries reached
“));
请问，这有可能是什么原因造成的？

这个是重传次数达到最大，有几个可能，

1. 远端的ack收不到，所以出现重传。
2. 底层没发送出去而丢弃掉了。

感觉像是第一种情况。第二种情况，因为TCP有重传机制，所以它不太可能出现，第一次发送失败，第二次。。。最后一次都发送失败。在这种情况下，只能抓抓包看看，看看远端的TCP ACK是否确实发送出来。还有就是，如果出现这种情况的时候，ping设备是否依然是通的。不如不通，就要看看网络中断是否能够正确产生了。

[attach]0[/attach]
今天抓包几个小时没有重现这个错误。上图是以前抓的包。从第21个帧开始192.168.19.41是PC，192.168.19.248是设备。设备应答[RST,ACK]。不知什么原因。
其他需要说明的：我今天发送数据90多M时，每帧发送长度由1024变为488，接着536，然后又488，后面就这样交替。这是设备接收能力不足，将TCP滑动窗口减小造成的吧。为什么会产生这种情况。是不是设备端程序有内存泄露什么的？

能否把这个抓包的报文发给我？看起来挺奇怪的，似乎和TCP Window有关系。

是否是内存泄露，只需要list_mem()多看几次就知道了。

能否把这个抓包的报文发给我？看起来挺奇怪的，似乎和TCP Window有关系。

是否是内存泄露，只需要list_mem()多看几次就知道了。

附件是抓的包。我的设备没有使用finsh。

你设置的TCP_WND挺小的，从报文来看，前面几次基本上需要设备回了确认才能发下一个包（甚至是初始的还出现了TCP重发）

后面的，像是设备上主动把TCP连接关闭了，只是主机侧的报文也奇怪了些，收到RST后，依然做了几次数据的重发(而且实际上这个数据报文已经是确认了)，而不是发送FIN, ACK

你设置的TCP_WND挺小的，从报文来看，前面几次基本上需要设备回了确认才能发下一个包（甚至是初始的还出现了TCP重发）

后面的，像是设备上主动把TCP连接关闭了，只是主机侧的报文也奇怪了些，收到RST后，依然做了几次数据的重发(而且实际上这个数据报文已经是确认了)，而不是发送FIN, ACK

TCP_WND设置的小只影响速度，对稳定性应该没有影响。现在就是不清楚设备为什么主动发[RST,ACK]。因为以前在ucos上用的LWIP1.2比较稳定。我们又将RTT上的LWIP换为1.2，目前测试3个设备大数据量通讯（每个都已通讯4G以上）都很稳定。

是的，TCP_WND只会影响速度，不会影响稳定性。

如果依然出现这个问题，你可以把TCP_RST_DEBUG宏打开看看，并且你也可以把lwip的debug信息输出到一个memory buffer上去，这样的话对性能影响也不会太大。当出现这个问题时，把memory buffer上的东西倒出来即可看到是因为什么而发送了RST。