工程师笔记 | Lwip中和 IP分包相关的参数

STM32单片机 2020-10-27





前不久接到一个客户的问题。在H743上需要通过UDP发送大的数据包,涉及到IP分包的问题。他们在测试的过程中遇到了只要发送6KBUDP数据包就会出现hardfault的问题。拿到这个问题的时候,调试得到了和客户一样的现象:


程序进入hardfault,并且是由Lwip协议栈的 

ip_reass_free_complete_datagram函数触发。后经过一番调试,搞清楚了问题的原因,要说清楚,我们得先来看看Lwip中IP分包的实现。


IP分包


因为以太网对一次传输数据的最大长度规定为1500字节,所以如果UDP的数据包大于这个长度,就会在IP层进行分包后,再通过以太网传输。用户数据通过UDP发送,数据封装的过程如下图:



IP首部一般是20字节,UDP首部8字节,1500-20-8=1472,所以当发送的用户数据超过1472个字节后,IP层就会分包。分包和重组的工作都是在IP层自动完成,对于UDP层来说,不用关心这个过程。


IP分包

Lwip中IP数据重组的实现


Lwip中通过ip_reassdata数据结构来描述一份正在被重组的IP数据报,其中的p字段指向第一个数据分片。Lwip中可以同时处理多个IP数据报的重组,每个IP数据报对应一个ip_reassdata数据结构,并且通过结构中的next指针构成一个单向的链表。reassdatagrams,指向ip_reassdata结构组成的链表的开头。


当以太网底层驱动接收到数据后,将数据传递给Lwip协议栈,ip_input函数会根据当前是IPv4还是IPV6调用对应的处理函数。在ip4_input中,通过检查IP首部中的标志位和分片偏移量,来判断当前是否是一个IP分片包。如果是就调用ip4_reass进行重组。


在整个IP数据报重组完成之前,接收到的IP分片包都保存在buffer中,如果其中的某个分片丢失,则重组就无法完成,而这些不全的IP分包数据不能一直占着buffer,所以在Lwip中定义了ip_reassdata的生存时间,每1秒执行一次ip_reass_tmr函数,将生存时间减1,当减到0后就删除对应的ip_reassdata数据结构,以及其上挂的所有数据分片pbuf。


IP分包

Lwip中IP数据分片的实现


发送的过程比接收的过程相对简单,大致就是:UDP层将要发送的数据组装在一个pbuf中,然后调用ip_output发送数据,当然在这个过程中,协议栈会添加相应的IP首部数据。如果IP数据报的长度大于以太网的MTU时,Lwip协议栈的IP层就会进行分片,将数据报分成两个或者更多进行发送。IP分片的工作是在ip_frag函数中完成的。


代码的实现在这里就不详细展开介绍了。我们这里主要讲的是,我们在应用Lwip的时候,哪些配置参数是需要注意的。


Lwip的相关配置参数


opt.h里有所有的Lwip默认配置,另外lwipopts.h中是应用程序中对lwip协议栈的配置。协议栈首先会去检查lwipopts.h中的参数,没有定义的再去检查opt.h。所以lwipopts.h中的配置会覆盖opt.h中的配置。这里我们只看和IP分片重组相关的部分。


IP_REASSEMBLY和IP_FRAG:如果需要支持IP重组和分片功能,这两个宏一定要设置为1。


IP_REASS_MAXAGE:IP分片包的生存时间,超过这个时间还没有收到所有的IP分片,则重组失败,已经收到的IP分片也将从协议栈中删除。以秒为单位。


MEMP_NUM_REASSDATA:可以同时进行IP重组的IP数据报的个数。这个数值是指整个IP数据报的个数,不是指IP分片的个数。


IP_REASS_MAX_PBUFS:指在ip_reassdata链表中挂接的,等待重组的pbuf的总个数。


MEMP_NUM_FRAG_PBUF:可同时发送的IP分片个数。


MEM_SIZE : heap大小,发送的数据越大,这个size就需要越大。


PBUF_POOL_SIZE:pbuf pool中buffer的个数,跟接收数据的大小有关。


PBUF_POOL_BUFSIZE:pbuf pool中每个buffer的大小,跟接收数据的大小有关。


问题分析


我们再回到一开始遇到的问题。


发送6KB的UDP数据,通过wireshark抓包可以看到,这6KB的数据被分成了5个IP分片发出来。但程序中只设置了4个ETH_RX_Buffer,每个buffer有1536个字节,虽然4个buffer加起来有6144字节,看起来刚好够我们发送的6KB。但我们要知道,STM32MAC层在接收数据的时候,一个以太网帧的数据可以放在多个ETH_RX_Buffer中,但一个ETH_RX_Buffer不能放多个帧的数据。


简单点说,就是MAC层即使只收到1个字节的数据,在当前的配置下,它也会占用掉一个1536字节的buffer。那现在PC端发来了5个IP分片,分别在5个以太网帧中,现在问题就很清楚了,因为我们只设置了4个ETH_RX_Buffer,所以轮到第5个以太网帧的数据过来的时候,ETH_RX_Buffer已经被占完了,没有空余的buffer来接收第5个以太网帧。


这里就不得不提到,


当前STM32Cube_FW_H7_V1.6.0的以太网底层驱动还有一个bug。在H7的驱动中,从底层驱动到lwip协议栈,使用了“零拷贝”的机制,也就是说,ETH_RX_Buffer的地址直接传递给lwip协议栈进行数据处理,不会再进行数据的拷贝。


但是,当前的驱动中,在low_level_input函数中,没有等lwip协议栈处理完ETH_RX_Buffer中的数据,接收 descriptor立刻就被还给ETH DMA了。这样当连续收到大量数据的时候,就会发生后面的数据把前面未处理完的数据覆盖掉的情况(ST官方已经在修改这个问题,在后续版本中会更新,当前可以通过增加ETH_RX_Buffer来解决这个问题)。



好,我们再回到前面的问题上,MAC接收到第5个以太网帧后,由于H7底层驱动的bug,就会将第一个ETH_RX_Buffer中的数据覆盖掉,这样导致lwip协议栈在处理时,因为收到了不完整,且被破坏的数据,出现了hardfault。如果将ETH_RX_DESC_CNT和对应ETH_RX_Buffer个数增加,就可以解决这个问题。当然MPU配置中,Descriptor对应的region范围也要调整大小,这里就不详说。



这个问题,如果继续增加发送的数据大小,就会发现还会遇到其他问题。


随着数据增大,IP分片也增多,


这样在ip_reassdata中挂接的pbuf也增多,


所以还需要关注IP_REASS_MAX_PBUFS的大小,相应进行调整。


而在发送大的数据出现IP分片的时候,


就需要关注MEMP_NUM_FRAG_PBUF,


MEM_SIZE以及发送descriptor的个数了。







STM32单片机 ST MCU (产品+工具+资料+技术+市场+活动)x 您的关注x您的支持 = STM32 单片机蝴蝶乐园
评论
热门推荐
相关推荐
我要评论
0
1
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦