Re: [lwip-users] WG: How to limit the UDP Rx packet size to avoid big RAM allocations

[address@hidden]

On 20.06.2018 09:49, R. Diez wrote:

My TCP/IP and lwIP expertise are limited. Please help me understand the situation by correcting my assumptions:

- The Ethernet driver has a fixed, limited number of DMA slots, so it already limits the amount of data at that level.

- An Ethernet frame is normally limited to 1500 bytes (or a little more). However, an UDP packet can be up to roughly 64 KiB long.

- In the case of large UDP (or even TCP) packets, lwIP is merging several Ethernet frames (IP fragmentation) into a large buffer (or a pbuffer chain). Therefore, it is "allocating" a bigger logical chunk. In the process of doing so, it could check whether some maximum reassembly packet size has been reached, and then discard the whole packet. Depending on the allocation strategy, that would significantly drop the temporary memory requirements.

- If I turn off IP_REASSEMBLY, would it help here? I guess the maximum size of UDP (or even TCP) packets would then be limited by the largest possible Ethernet frame. Would turning off IP_REASSEMBLY break other things, or severely impact performance, at least on IPv4?

Unless you expect to get fragmented packets, you should be able to safely turn off reassembly. However, you *may* get fragmented packets when connected to some larger network (like the internet) where there maybe routes that require fragmentation because they have MTUs smaller than 1500 bytes. This is the case e.g. for PPPoE or some IP4-in-IPv6 tunnels and others.

- Is there some constant to limit the size in bytes of reassembled packets? I found IP_REASS_MAX_PBUFS, but that is not a byte limit. If I set it too low, it may break, because the sender may choose to send many small packets. If I set it too high, the sender could send few but large frames and trigger big memory allocations.

No, such a config option does not exist. However, you never trigger 'big memory allocations'. All you have is a linked list of all the small packets. The stack does not copy them into one big memory block. And from a DoS perspecive, those many small allocations are not worse than getting many partly received fragments of different IP packets, or am I wrong there?

Simon