Am 17.02.2020 um 12:33 schrieb Adam Fullerton: > Hi, > > I am in the process of upgrading a remote monitoring system that used > lwip-1.3.2 to 2.1.2. It all went very well but I am having issues with > some of the options. The application uses the sockets API exclusively. > In lwipopts.h I have the following: > > /* Memory options */ > #define MEM_LIBC_MALLOC 1 > #define MEMP_MEM_MALLOC 1 > #define MEMP_MEM_INIT 1 > #define MEM_ALIGNMENT 4 > #define MEM_SIZE (1024U * 1024U * 3U) > /* Define the padding to align the payload on a 4 byte boundary */ > #define ETH_PAD_SIZE 2 > > The issue I experienced was that the call-back function pointers were > not initialised so the system would randomly crash. I have added a call > memset in the allocator which has fixed the problems. However now the > pbuf memory is zero’d which I see as unnecessary. What is the correct > way to configure lwip to use the c library malloc?.
That should not be necessary. Maybe there's some zeroing out missing and we normally don't see this problem because lwIP pools are allocated from bss (which is zeroed at startup by C definition). Could you provide more information on this and put it into a savannah bug so that this does not get forgotten? > > What is the define which controls the number of sockets that can be open > at one time? > > #define MEMP_NUM_NETCONN 64 > #define MEMP_NUM_TCP_PCB 64 > #define MEMP_NUM_TCPIP_MSG_INPKT 64 > #define MEMP_NUM_TCP_PCB_LISTEN 64 When using heap for allocation (not memp), most of these defines are not used. With the exception of MEMP_NUM_NETCONN, which is used for the array of sockets. > > When a web browser loads some of the more complex web pages the web > server reports a socket write error, usually on about the 20th file > linked by the page. > > Also large files (> 2Mbyte) now fail to download. Is there anything > that controls the maximum size of a transfer over a socket? Ehrm, there are defines conttrolling memory options, but there's not a single option controlling download size. I guess you'll have to debug that by looking at 'lwip_stats'. Look for the 'err' members... Regards, Simon _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users