“
前不久接到一个客户的问题。在H743上需要通过UDP发送大的数据包，涉及到IP分包的问题。他们在测试的过程中遇到了只要发送6KB的UDP数据包就会出现hardfault的问题。拿到这个问题的时候，调试得到了和客户一样的现象：
程序进入hardfault，并且是由Lwip协议栈的
ip_reass_free_complete_datagram函数触发。后经过一番调试，搞清楚了问题的原因，要说清楚，我们得先来看看Lwip中IP分包的实现。
因为以太网对一次传输数据的最大长度规定为1500字节，所以如果UDP的数据包大于这个长度，就会在IP层进行分包后，再通过以太网传输。用户数据通过UDP发送，数据封装的过程如下图：
IP首部一般是20字节，UDP首部8字节，1500-20-8=1472，所以当发送的用户数据超过1472个字节后，IP层就会分包。分包和重组的工作都是在IP层自动完成，对于UDP层来说，不用关心这个过程。
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。
发送的过程比接收的过程相对简单，大致就是：UDP层将要发送的数据组装在一个pbuf中，然后调用ip_output发送数据，当然在这个过程中，协议栈会添加相应的IP首部数据。如果IP数据报的长度大于以太网的MTU时，Lwip协议栈的IP层就会进行分片，将数据报分成两个或者更多进行发送。IP分片的工作是在ip_frag函数中完成的。
代码的实现在这里就不详细展开介绍了。我们这里主要讲的是，我们在应用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的个数了。
