Re: [lwip-users] Memory leak due to synthesized DDoS

[address@hidden]

Am 26.10.2022 um 03:46 schrieb Stephen Cowell:
> My product is a modbus TCPIP board, using the Atmel SAM4E16E based off
> of the SAM4E-EK.  It is using LWiP 1.4.1 with pbuf.c and pbuf.h from
> version 2.1.3.  I know... cringe... but I did this recently, during
> troubleshooting... helped some, see below.
>
> I'm banging it real hard using DaqFactory to create two simultaneous
> threads sending modbus requests to the same port/address.  As I do this
> I can see the pbuf_pool pbufs being created higher and higher up the
> pool... I can debug on the pbuf deallocation and see that the ->next is
> NULL, so there is no connection to the rest of the chain.  If I let this
> go on for long enough the processor will hard fault.
>
> I had this behavior happen very quickly before I moved from LWiP mem
> management to GNU C library malloc()... now it takes a long time to
> die.  Also, after I spliced in the pbuf code from the latest-greatest it
> did seem to become more robust... but I can still watch the allocated
> pbufs climb up the pool, leaving behind orphan pbufs as a memory leak.
>
> I guess my main question is... should LWiP be able to survive this kind
> of abuse?  I'm able to hit it with requests about every two
> milliseconds... and it takes about an hour before it runs out of
> memory.  Would I notice any improvement by completing the port to 2.1.3
> (a significant effort)?  Is LWiP tested in this way?  It's worth noting
> that DaqFactory is glitching the inputs it receives sometimes... but
> Wireshark shows them to be rock solid (when there's not a timeout or
> port locked complaint).  Am I abusing it too hard? Thanks for your
> time... Steve.

No, I have been stressing lwIP equally or more. There should be no
problem. You may run out of memory, but not get a hard fault.

Most problems like that have come from a buggy port or driver, or from
invalid usage of lwIP regarding threading (and even with NO_SYS, you can
be active in the code from main loop and from interrupts and thus need
to pay attention to the threading requirements!).

Rergards,
Simon