Thu 22 May 2014 07:38:52 PM UTC, comment #7:
Not really a bug, and the recently merged ppp-new branch already have numerous memory improvement.
|
Mon 07 May 2012 08:58:54 PM UTC, comment #6:
Isn't the MEM_USE_POOLS define the way to use pbuf instead of the heap ?
Of course I will rework the patch to make it optional and I don't care at all if it is accepted or not, I just want to understand better the current LwIP strategy to provide better patchs :-)
|
Mon 07 May 2012 08:28:10 PM UTC, comment #5:
No, there's not a strategy to remove the heap, but personally, I'd like the stack to be usable without a heap to prevent heap fragmentation of being a potential problem in long running systems.
BTW: DHCP and AutoIP can be prevented to use the heap, PBUF_RAM pbufs can be diverted to memp pools of different size (but in this mode, the heap replacement should only be used for pbufs).
I'm not saying your idea is bad, I only want the heap to be "optional". :-)
|
Mon 07 May 2012 12:25:15 PM UTC, comment #4:
Humm, maybe I misunderstood something.
Am I wrong saying that mem_malloc() and mem_free() use memory from ram_heap[] (if LWIP_RAM_HEAP_POINTER is undefined as well as MEM_USE_POOLS, which are the default) ?
Some other files are using mem_malloc/mem_free: lwip/src/core/dhcp.c, lwip/src/core/ipv4/autoip.c and lwip/src/core/pbuf.c use mem_malloc if type is PBUF_RAM, is the current lwip strategy to remove all calls to mem_malloc/mem_free ?
|
Thu 03 May 2012 07:04:20 PM UTC, comment #3:
Hmm, making the heap mandatory is not my favourite. I'd make this at least optional since I want lwIP to support devices without a heap.
Can't we reuse/share another PPP-internal buffer?
Oh, and added to that: although the PPP code is not in best shape everywhere, we try to keep changes to the original code (samba pppd) as small as possible, while applying your patch probably brings us more differences. I'll have to think about that...
|
Mon 30 Apr 2012 08:35:38 AM UTC, comment #2:
As a side note:
Calling ethernet_input() from a thread other than the LwIP thread is a bad idea, this is not a thread-safe way, this was discussed on the lwip-users mailing list and was a bug in the port I used.
This doesn't change anything about the huge stack requirement, except that it now requires stack memory on the LwIP thread.
|
Thu 26 Apr 2012 02:55:24 PM UTC, comment #1:
Hum, there is a short glitch in the patch, all LOG_ERROR must be replaced by LOG_ERR, I should have read the debug.h header before :-)
|
Wed 25 Apr 2012 01:02:35 PM UTC, original submission:
The current PPP CHAP implementation requires a lot of stack memory, let's say, about 1 KiB stack memory is required to complete the challenge:
static void ChapReceiveResponse(...) {
...
char secret[MAXSECRETLEN]; // 256
char rhostname[256];
MD5_CTX mdContext; // 64+16+44+24 = 104
static void ChapSendResponse(...) {
...
char msg[256]; /* @todo: this can be a char, no strcpy needed /
This can be an issue with system without much memory, if Ethernet input is done through a thread that call ethernet_input() from etharp.c, then this thread is going to require about 1 KiB of static stack size only necessary for CHAP, which is only used from time to time (ideally, only one time).
Here is a patch that use mem_malloc() and mem_free() for heavy CHAP authentication data, so that it use memory from the mem/packet pool and doesn't waste memory.
It also uses the MAXNAMELEN define instead of the literal 256 there and there.
Sylvain
|