最近在用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的软件校验给打开。
就不再丢包了，并且再次遇到0xffff校验和的包，也能够被收到了：
所以，我的结论就是：GD32的MAC控制器的硬件校验存在bug，只要遇到校验和0xffff的包，就不把他丢掉。解决办法：关闭硬件校验，使用LWIP的软件校验。
这也解释了为什么我关闭了socket链接，反而能够将缓冲区的包发出去了，因为关闭连接之后发的包，flag字段不一样，也就导致校验和不是0xffff，所以能够被GD32接收。
同时后来我查约到了另一个网友的帖子：GD32F407ZET6+LAN8720，DMA以太网移植LWIP协议栈，UDP通信ping测试每65535包丢一包 - GD32 MCU - 电子工程世界-论坛 (eeworld.com.cn)
每65535丢一个包，这不就是uint16的范围吗？估计原因和我这个一样，遇到0xffff了。所以啊，估计GD32的不止一款芯片的MAC控制器有问题，大家开发这个的时候注意别踩坑！
后面问了代理商的技术支持，暂未回复
