GD32F470+lwip 丢包问题分析及解决

news2024/10/6 8:32:55

最近在用GD32和管理机之间用TCP协议开发一个功能，功能都没问题，后面跑大量发包时候的连续测试时，总是会出现偶发性的，大概几分钟到数十分钟的一次丢包。尽管在应用层做了超时机制，一旦超时就会重新建立socket链接并重新发包，但是这样做太丑陋了，而且断开重连延时太大了，还是想彻底搞清楚这个个问题。所以先抓包吧。

管理机使用TCP dump抓包，要加-v选项，不然后面无法从通信流程上看到问题所在（最开始没加，以为是其它问题，愣是分析了半天也没想出所以然）。注意：cksum 0x5295 (incorrect -> 0x0026）的字样不是说我校验和没对，而是校验和的计算是放在了mac控制器硬件计算，而tcpdump抓包的时候，处于mac计算之前，所以这时候检验和不对是正常的，这个功能叫做offload，可以关闭的。

然后在GD32中打开lwip的debug选项，也进行了抓包

抓完包之后，进行分析，由于篇幅有限就不放全部的抓包日志了，跟大家讲下这中间发生了什么。

先看管理机tcpdump日志，我的程序会发送数据位25字节大小的报文，GD32收到并执行操作后返回12字节的报文，就是一来一回这样收发。

可以看到前面25,12,25,12，交替的报文收发是正常的，但是突然就有这么一个包，嘿，发不出去了，所以一直在重发，重发很多次也收不到ack。直到什么时候才发出去呢？直到我应用程序关闭了链接，在TCP协议关闭前最后一次发送缓冲区的剩余内容时，他发出去了，并且收到了GD32的ack。

再来看看GD32的抓包，简而言之，除了那个管理机一直重发发不出去的包，前后所有的包，GD32都收到了。

后来我进行了多次试验，实验结果均是如此。一开始我还没有注意校验和这个字段，光分析TCP协议去了，什么nolelay啊，什么快速重传，以及很多配置都用过了，均失败了。后来吧tcpdump的-v选项打开，偶然间看到发这个重传的包的校验和是0xffff，卧槽这个可太敏感了，不是什么0x1234，也不是0x9876，偏偏是这个十六位检验值的边界！所以大胆假设，只有校验和恰好是0xffff的才会丢包。再做做实验，真的每次都是这个0xffff的包发不出去！

于是，我查阅手册，把GD32的MAC控制器的硬件校验给关掉，再把LWIP的软件校验给打开。