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

[address@hidden]

On 27.06.2018 13:31, R. Diez wrote:
> > It does. Input pbufs are PBUF_POOL pbufs which consume a constant memory size.
> I'm no expert,

Yet you try to sound like one ;-)

> but that sounds wrong. If the remote computer decides to
> send very small chunks, lwIP is going to waste memory fast.

No. On the contrary, your system has to be able to cope with what's 
coming in. An PBUF_POOL pbufs don't always consume one 1514 byte chunk 
but instead are a chain of smaller chunks (see PBUF_POOL_BUFSIZE).

> That's no good on embedded systems.

That's your assumption. My assumption is not that an embedded system has 
little RAM but that an embedded system has to run stable and cope with 
what it has. Of course, wasting RAM is no good, but using pool elements 
of constant size has advantages over using different-sized allocations.

> Anyway, I am using these at the moment:
>
> #define MEM_LIBC_MALLOC 1
> #define MEMP_MEM_MALLOC 1
>
> So I guess what you say does not hold, at least in this scenario.

As a matter of fact, it does. That's why I wrote it. MEM_LIBC_MALLOC is 
of no interest, here. MEMP_MEM_MALLOC uses the heap to allocate chunks 
of the pool's element size the pool would normally have. As such, 
PBUF_POOL pbufs still allocate a constant size (PBUF_POOL_BUFSIZE + 
struct pbuf + alignment). That might not be what you expected, but it's 
what it's like, currently.


> > The problem I see is: how do you know the reassembled size in advance?
> Do you not get an offset within each fragment? If the offset is too big,
> you know that the final packet size is over the limit, so you can
> discard at least those fragments quickly. And any other fragment under
> that offset too that you have already received.

So you propose to abort receiving the packet when the first fragment 
arrives that is behind the configured size range. That would work, but I 
would not see this as preventing an attack, as it's much easier to just 
send multiple fragments with different IP_ID and still waste all your 
memory. We'll need a different approach here, I think.

Simon