本文主要是介绍GD32F470+lwip 丢包问题分析及解决,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
最近在用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控制器有问题,大家开发这个的时候注意别踩坑!
后面问了代理商的技术支持,暂未回复
这篇关于GD32F470+lwip 丢包问题分析及解决的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!