Re: [lwip-users] Any known bugs in LWIP's internal heap?
That's great to hear. Quite a lot of heap sources out there have some weird "feature" like that. The more I dig into this the more different code I find which does this. If there were issues deep inside LWIP I would never find them. The functionality is way too complex for me to troubleshoot it at that level. Many thanks, Peter > > > Peter wrote: >>Does anyone know if LWIP's internal heap management has this issue >> >>https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/ > >Ehrm, that's newlib. Why should we have the same bug? Did you meet any >problems with the lwip heap? There are no known bugs there that I know of. > >Regards, >Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Any known bugs in LWIP's internal heap?
Does anyone know if LWIP's internal heap management has this issue https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/ Basically, the workaround in that particular case was to malloc and immediately free the largest possible block. That was a bug in a commonly used (Newlib) heap library. This issue seems quite widely known. LWIP and FreeRTOS, and TLS all have their internal heap managers. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip-users Digest, Vol 234, Issue 6
>Subject: [lwip-users] LwIP Project Question Here is a sample lwipopts.h which I have spent made days or weeks on. It contains a lot of potentially useful comments. A lot of it won't apply to your project. The values override defaults in opt.h. I am running under FreeRTOS. LWIP has been largely abandoned now. It is very good but it is now over 15 years old and most of the people working on it have moved on, so getting support is hard. You can try e.g. here https://www.eevblog.com/forum/microcontrollers/anyone-here-familiar-with-lwip/ /** ** * @fileLwIP/LwIP_HTTP_Server_Netconn_RTOS/Inc/lwipopts.h * @author MCD Application Team * @brief lwIP Options Configuration. ** * * This sort of explains the memory usage * https://lwip-users.nongnu.narkive.com/dkzkPa8l/lwip-memory-settings * https://www.cnblogs.com/shangdawei/p/3494148.html * https://lwip.fandom.com/wiki/Tuning_TCP * https://groups.google.com/g/osdeve_mirror_tcpip_lwip/c/lFYJ7Fw0Cxg * ST UM1713 document gives an overview of integrating all this. * * * * * * * * */ #ifndef __LWIPOPTS_H__ #define __LWIPOPTS_H__ /** * NO_SYS==1: Provides VERY minimal functionality. Otherwise, * use lwIP facilities. */ #define NO_SYS 0 // Flag to make LWIP API thread-safe. The netconn and socket APIs are claimed // to be thread-safe anyway. The raw API is never thread-safe. // A huge amount of online discussion on this topic; most of it unclear, but // ON (1) seems to be recommended, as being more efficient. #define LWIP_TCPIP_CORE_LOCKING 1 // If LWIP_TCPIP_CORE_LOCKING=0 then these two need to be 1 // See https://www.nongnu.org/lwip/2_1_x/multithreading.html //#define LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT 1 //#define SYS_LIGHTWEIGHT_PROT1 // This places more objects into the static block defined by MEM_SIZE. // Uses mem_malloc/mem_free instead of the lwip pool allocator. // MEM_SIZE now needs to be increased by about 10k. // It doesn't magically produce extra memory, and causes crashes. // There is also a performance loss, apparently. AVOID. #define MEMP_MEM_MALLOC 0 //NC: Need for sending PING messages by keepalive #define LWIP_RAW1 #define DEFAULT_RAW_RECVMBOX_SIZE 4 // For ETHSER #define LWIP_TCP_KEEPALIVE 1 /*-*/ /* LwIP Stack Parameters (modified compared to initialization value in opt.h) -*/ /* Parameters set in STM32CubeMX LwIP Configuration GUI -*/ /*- Value in opt.h for LWIP_DNS: 0 -*/ #define LWIP_DNS 1 /* -- Memory options -- */ /* MEM_ALIGNMENT: should be set to the alignment of the CPU for which lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2 byte alignment -> define MEM_ALIGNMENT to 2. */ #define MEM_ALIGNMENT 4 /* * MEM_SIZE: the size of the heap memory. This is a statically allocated block. You can find it * in the .map file as the symbol ram_heap and you can see how much of this RAM gets used. * If MEMP_MEM_MALLOC=0, this holds just the PBUF_ stuff. * If MEMP_MEM_MALLOC=1 (which is not reliable) this greatly expands and needs 16k+. * Empirically this needs to be big enough for at least 4 x PBUF_POOL_BUFSIZE. * This value also limits the biggest block size sent out by netconn_write. With a MEM_SIZE * of 6k, the biggest block netconn_write (and probably socket write) will send out is 4k. * This setting is mostly related to outgoing data. */ #define MEM_SIZE(6*1024) // MEMP_ structures. Their sizes have been determined experimentally, by // increasing them and seeing free RAM changing. /* MEMP_NUM_PBUF: the number of memp struct pbufs. If the application sends a lot of data out of ROM (or other static memory), this should be set high. */ //NC: Increased to 20 for ethser #define MEMP_NUM_PBUF 20 // each 1 is 20 bytes of static RAM /* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One per active UDP "connection". */ #define MEMP_NUM_UDP_PCB6 // each 1 is 32 bytes of static RAM /* MEMP_NUM_TCP_PCB: the number of simultaneously active TCP connections. */ //NC: Increased to 20 for ethser #define MEMP_NUM_TCP_PCB20 // each 1 is 145 bytes of static RAM //NC: Have more sockets available. Is set to 4 in opt.h #define MEMP_NUM_NETCONN10 /* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections. */ //NC: Increased to 20 for ethser #define MEMP_NUM_TCP_PCB_LISTEN 20 // each 1 is 28 bytes of static RAM /* MEMP_NUM_TCP_SEG: the number of simultaneously queued TCP segments. */ // Was 8; increased to 16 as it improves ETHSER reliability when running // HTTP server
[lwip-users] lwIP UDP echo server fails to send message
AFAIK there is no support forum or "community" for LWIP today. It is a project which was at its height about 15 years ago and the devs have generally moved on long ago. This also means that if somebody develops a solution for something, they have nowhere to post it. Googling digs up lots of old stuff, mostly pre-2011. There is also a lot of clickbait - sites which collate content from other sites. I post questions all over the place (EEVBLOG, the ST forum) and occassionally somebody bites, or I find someone who replies privately. I doubt LWIP has any obvious bugs after all these years but there is certainly some complex behaviour related to how much buffering has been allocated. Like that business of broadcast packets messing stuff up. Peter >Send lwip-users mailing list submissions to > lwip-users@nongnu.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/lwip-users >or, via email, send a message with subject or body 'help' to > lwip-users-requ...@nongnu.org > >You can reach the person managing the list at > lwip-users-ow...@nongnu.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of lwip-users digest..." > > >Today's Topics: > > 1. Re: lwIP UDP echo server fails to send message lengths of > 4385 & 4386 (Dan Nygren) > 2. Re: lwIP UDP echo server fails to send message lengths of > 4385 & 4386 (Sylvain Rochet) > 3. lwIP deInit (Thompson, Jeff) > 4. Re: lwIP UDP echo server fails to send message lengths of > 4385 & 4386 (Dan Nygren) > > >-- > >Message: 1 >Date: Fri, 3 Feb 2023 13:24:48 -0800 >From: Dan Nygren >To: lwip-users@nongnu.org >Subject: Re: [lwip-users] lwIP UDP echo server fails to send message > lengths of 4385 & 4386 >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >Peter wrote: > >> 4385/4386 could be 3x MTU ? ... > >Peter, thanks for responding! >Yes, it seems like I've hit some corner case. >Is this the right place to notify the lwIP maintainers of problems? This is >not a current problem for me as my messages are under the MTU size. I just >hit this while developing some diagnostics for my board and I wanted to let >others know about it. > >Dan > >, >On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren wrote: > >> Hello fellow lwIP users. Can anyone point me in the right direction on how >> to resolve or report to the right folks the below issue? >> >> I'm seeing rather bizarre behavior in that messages of length 4385 and >> 4386 I send to a lwIP based UDP echo server are not received back. >> udp_sendto() appears to be getting called and completing successfully. >> Wireshark indicates there are "bogus, payload length" errors with these >> lengths. >> >> I have a detailed write up showing the behavior here: >> https://github.com/Xilinx/embeddedsw/issues/212 >> >> I can copy the info above into an email for this mailing list if you >> prefer. >> >> Let me know your suggestions on how to proceed. ... Dan Nygren >> >> , >> >-- next part -- >An HTML attachment was scrubbed... >URL: ><https://lists.nongnu.org/archive/html/lwip-users/attachments/20230203/8c0970a1/attachment.htm> > >-- > >Message: 2 >Date: Fri, 3 Feb 2023 22:39:15 +0100 >From: Sylvain Rochet >To: Mailing list for lwIP users >Subject: Re: [lwip-users] lwIP UDP echo server fails to send message > lengths of 4385 & 4386 >Message-ID: <20230203213915.ga17...@gradator.net> >Content-Type: text/plain; charset="utf-8" > >Hi, > >On Fri, Feb 03, 2023 at 01:24:48PM -0800, Dan Nygren wrote: >> Peter wrote: >> >> > 4385/4386 could be 3x MTU ? ... >> >> Peter, thanks for responding! >> Yes, it seems like I've hit some corner case. >> Is this the right place to notify the lwIP maintainers of problems? This is >> not a current problem for me as my messages are under the MTU size. I just >> hit this while developing some diagnostics for my board and I wanted to let >> others know about it. > >This kind of issues set all red lights to full brightness about a low >level driver issue or a buggy MAC offloader on fragmented IP packets. > >Anyway, basic rule about using fragmented IP packets: avoid (to not say >don't). > >Sylvain >-- next part -- >A non-text attachment was scrubbed... >Name: signature.asc >
[lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386
4385/4386 could be 3x MTU ? Not a lot surprises me, after spending many days on this https://www.eevblog.com/forum/microcontrollers/anyone-here-familiar-with-lwip/msg4660942/#msg4660942 Peter >Send lwip-users mailing list submissions to > lwip-users@nongnu.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/lwip-users >or, via email, send a message with subject or body 'help' to > lwip-users-requ...@nongnu.org > >You can reach the person managing the list at > lwip-users-ow...@nongnu.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of lwip-users digest..." > > >Today's Topics: > > 1. lwIP UDP echo server fails to send message lengths of 4385 & > 4386 (Dan Nygren) > > >-- > >Message: 1 >Date: Wed, 1 Feb 2023 14:10:10 -0800 >From: Dan Nygren >To: lwip-users@nongnu.org >Subject: [lwip-users] lwIP UDP echo server fails to send message > lengths of 4385 & 4386 >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >Hello fellow lwIP users. Can anyone point me in the right direction on how >to resolve or report to the right folks the below issue? > >I'm seeing rather bizarre behavior in that messages of length 4385 and 4386 >I send to a lwIP based UDP echo server are not received back. udp_sendto() >appears to be getting called and completing successfully. Wireshark >indicates there are "bogus, payload length" errors with these lengths. > >I have a detailed write up showing the behavior here: >https://github.com/Xilinx/embeddedsw/issues/212 > >I can copy the info above into an email for this mailing list if you prefer. > >Let me know your suggestions on how to proceed. ... Dan Nygren > >, >-- next part -- >An HTML attachment was scrubbed... >URL: ><https://lists.nongnu.org/archive/html/lwip-users/attachments/20230201/1ad35278/attachment.htm> > >-- > >Subject: Digest Footer > >___ >lwip-users mailing list >lwip-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/lwip-users > > >-- > >End of lwip-users Digest, Vol 234, Issue 1 >** ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Can one find out how much data can be sent (lwip_write) to a NON blocking socket without loss of data?
Thank you for your reply.
I don't understand how FD_ISSET can be used to work out when one can
write to the socket.
However, I have implemented the short socket write:
//read rx_len bytes from the buffer and send over ethernet
rx_len = serial_receive(i, buf, rx_len);
if (rx_len > 0)
{
int tmp_len;
bool fail = false;
// This returns # bytes actually written (if a positive
value)
tmp_len = write(ethser_port[i].client_fd, buf, rx_len);
if (tmp_len<0) fail=true;
// Process the case where not all rx_len bytes were
written (by the NON blocking socket)
// This can cause a wait here if the other end is slow
in consuming the data.
if ( (tmp_len0 ) && !fail );
}
if ( fail )
{
//something went wrong. Close the client socket
close(ethser_port[i].client_fd);
ethser_port[i].client_fd = -1;
continue; //break from the for-loop early
}
ethser_port[i].rx_count += rx_len;
}
If I understand it right, the socket write returns # of bytes actually
written, or various negative values for error conditions. Or it could
return zero if you asked it to write zero bytes, I assume.
I am always writing from a 512 byte buffer (containing 1-512 bytes) so
if the write returns say 256, then I need to repeat the write with a
length of 256 and with the start of the data being [256].
>Hello Peter,
>
>On 2022-12-22 00:20, Peter wrote:
>> Unfortunately the socket is non-blocking so if the data is
>> arriving too fast, some gets lost.
>
>This is the most common mistake made with TCP socket programming:
>
>Not handling short writes properly.
>
>You also get this with blocking sockets, those also don't guarantee
>to send all supplied data. In practice, you always get a short write
>before the socket would block.
>
>If you don't want short writes, use the RAW API.
>
>> The obvious solution (make the socket blocking) would cause
>> problems elsewhere.
>>
>> Is there some way to get how many bytes a write socket can accept?
>
>Check and handle the send return value correctly.
>
>> Doing some digging around, I have found stuff like this
>>
>> //socket ready for writing
>> if(FD_ISSET(new_sd, _flags)) {
>> //printf("\nSocket ready for write");
>> FD_CLR(new_sd, _flags);
>> send(new_sd, out, 255, 0);
>> memset(, 0, 255);
>> } //end if
>>
>> but it doesn't seem to be suitable.
>
>This solves your real problem: Knowing when to send more data.
>
>(Assuming your send rate is not consistently too high for the
>receiver to keep up, and your code does sends in bursts.)
>
>>
>> Is there some way to get a buffer_space() function, so I can
>> extract only that many bytes (max) out of the UART buffer?
>
>send() returns how many bytes are sent, you just have to keep the
>remainder and send that when the socket can accept more (see above).
>
>Greetings,
>
>Indan
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Can one find out how much data can be sent (lwip_write) to a NON blocking socket without loss of data?
I have code (not mine) which reads a serial port buffer, finds out how
many bytes are in it, and transmits that to a socket.
Unfortunately the socket is non-blocking so if the data is arriving
too fast, some gets lost.
The obvious solution (make the socket blocking) would cause problems
elsewhere.
Is there some way to get how many bytes a write socket can accept?
For reading from a socket, there appears to be a hack where you give
it a zero block length, but I can't find anything for writing to a
socket.
This is the basic code:
if ((rx_len > 0) )
{
//read rx_len bytes from the buffer and send over ethernet
rx_len = serial_receive(i, buf, rx_len);
if (rx_len > 0)
{
if (write(ethser_port[i].client_fd, buf, rx_len) <0)
{
//something went wrong. Close the client socket
dbg_printf("EthSer Closing client idx: %d fd: %d", i,
ethser_port[i].client_fd);
close(ethser_port[i].client_fd);
ethser_port[i].client_fd = -1;
continue; //break from the for-loop early
}
}
}
where write() is a macro for lwip_write().
Doing some digging around, I have found stuff like this
//socket ready for writing
if(FD_ISSET(new_sd, _flags)) {
//printf("\nSocket ready for write");
FD_CLR(new_sd, _flags);
send(new_sd, out, 255, 0);
memset(, 0, 255);
} //end if
but it doesn't seem to be suitable.
Is there some way to get a buffer_space() function, so I can extract
only that many bytes (max) out of the UART buffer?
Thank you in advance.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] LWIP and its keep-alive feature - does it work?
Hi All, Does anyone know whether the keep-alive feature in LWIP TCP actually works, and if so, are there any unusual limitations? I have a system described here https://www.eevblog.com/forum/networking/sockets-keep-alive-and-vpns/ comprising of a client and a server (both embedded, LWIP/FreeRTOS, STM 32F417). The KA option is apparently enabled with the calls described in the above link, and it seems to do "something" (in that if running this over a VPN, the VPN remains UP, instead of hanging up after some time) but if say the server is rebooted during a connection, the connection is not re-established. Maybe that is how it is supposed to work i.e. if one wanted to re-establish a connection in such a situation, the client should be sending out regular "real" packets, not KA packets. Needless to say I have googled everywhere and all I find is people having problems with LWIP KA but nobody posting solutions. Thank you in advance, Peter ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LwIP v2.1.2 in UDP client mode gets stuck in etharp_query() after running for a long time without connection?,
One needs to be careful with thread safety because stuff can apparently work for a long time, and then breaks when timing changes. Netconn should be thread safe if different RTOS tasks use different handles. It's a bit like serial ports; they will never be thread safe (obviously). LWIP achieves thread safety by using internal messaging, which is atomic. That is my understanding. >On Fri, 23 Sep 2022 11:04:55 +0100 Peter wrote: > >> >> I have been told by an "expert" that the RAW API is *never* thread >> safe. >> >> The core locking feature is just a more timing-efficient way of doing >> things, but the LWIP netconn and sockets APIs are thread-safe anyway. >> >> >Hi Peter, > >I'm glad to hear from you. > > >I've found a raw function that is thread safe: tcpip_try_callback() >function. > >Though according to the doc: >https://www.nongnu.org/lwip/2_1_x/multithreading.html, >only the functions from these API header files are thread-safe: api.h, >netbuf.h, netdb.h, netifapi.h, pppapi.h, sockets.h, sys.h. > >I saw a note above the tcpip_try_callback() function, it said that the >function can be called in interruption. However, tcpip_try_callback() >function is not in the API header files mentioned above! > >Maybe it's because the maintenance of the docs is a bit behind the updates >to the code. I think we should go with source code and actual test results. > > >Netconn is not always thread safe. >Suppose there are two threads and one netconn, one thread receives through >this net conn while another thread sends through this net conn, in this >case netconn is not thread safe. >More details can be seen in this link: >https://lists.gnu.org/archive/html/lwip-users/2009-05/msg00049.html > > >Last but not least, when you send an email to the lwip-user mail list, >please follow these steps: >1. Edit the contacts to "lwip-users@nongnu.org" >2. Edit the subject to the thread title that you want to join in or reply >to. (This can make your mail be archived in the mail list in the same >subject.) >3. Clear the content of the email if you send a new email by clicking the >reply button. (This can make your email more readable.) >4. Just write what you want to write and send it. >Please don't reply to the lwip-users Digest mail directly or use a subject >name just like "lwip-users Digest, Vol 229, Issue 13". It's confusing a lot. > > >If my understanding is different from yours, exchange of ideas is very >welcome. > >Best regards, >Lan ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip-users Digest, Vol 229, Issue 12
I have been told by an "expert" that the RAW API is *never* thread safe. The core locking feature is just a more timing-efficient way of doing things, but the LWIP netconn and sockets APIs are thread-safe anyway. >Send lwip-users mailing list submissions to > lwip-users@nongnu.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/lwip-users >or, via email, send a message with subject or body 'help' to > lwip-users-requ...@nongnu.org > >You can reach the person managing the list at > lwip-users-ow...@nongnu.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of lwip-users digest..." > > >Today's Topics: > > 1. Re: LwIP v2.1.2 in UDP client mode gets stuck in > etharp_query() after running for a long time without connection? > (Lan Yang) > 2. Re: why is my stack usage so high for the tx thread hosted by > lwip? (Bas Prins) > > >-- > >Message: 1 >Date: Fri, 23 Sep 2022 15:36:14 +0800 >From: Lan Yang >To: lwip-users@nongnu.org, goldsi...@gmx.de >Subject: Re: [lwip-users] LwIP v2.1.2 in UDP client mode gets stuck in > etharp_query() after running for a long time without connection? >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >On Fri, Sep 23, 2022 at 12:22 AM Simon Goldschmidt wrote: > >> Looks like yet another threading issue. Or in other words, it seems like >> you are using lwip in a wrong way, resulting in Rx processing, tx >> processing and possibly timer processing being active in the code at the >> same time. >> >> Regards, >> Simon >> > >Hi Simon, > >Thank you! Your reply has given me more confidence in my test results. >After a lot of tests, I find it stuck because I use an un-thread safe >function "udp_send()" outside the tcpip_thread. > >I read a lot of the lwip-user archives. They help me a lot. >https://lists.gnu.org/archive/html/lwip-users/2009-05/msg00049.html >https://lists.gnu.org/archive/html/lwip-users/2022-07/msg00012.html >https://lists.gnu.org/archive/html/lwip-users/2010-04/msg00053.html > > >And now I found two ways to resolve the problem. >I would like to ask for your advice about which way is more recommended. > >The first method: >Just use LOCK_TCPIP_CORE() and UNLOCK_TCPIP_CORE() to protect the other >threads which need to call the LwIP's raw api (such as udp_send()). > >The second method: >use the tcpip_try_callback() function in the other threads(outside the >tcpip_thread) to post message to tcpip_thread, and when the tcpip_thread >handle its message, it will call the according callback function, and then >I can call the LwIP's raw api (such as udp_send()) in the callback function >which is called by the tcpip_thread. > >Both methods have passed my test. They all work well. >Which method is more recommended? > >Best regards, >Lan ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] why is my stack usage so high for the tx thread hosted by lwip?
I will be amazed if you find anybody who knows what most of the options in the lwipopts.h file do *and* is willing to post it. LWIP is a typical open source piece of code, unsupported and those who developed it have moved on to more interesting things many years ago. So the web is full of desperate people posting everywhere asking questions like this. I have spent a chunk of my life this year messing about with this stuff. LWIP does actually work very well, which is just as well considering the above! One thing I found is that the buffer config makes practically no difference to performance in a typical embedded system (i.e. not a 3GHz PC CPU!). So I was able to achieve a big reduction in the memory usage. Below is my lwipopts.h file with comments which I believe to be correct. /** ** * @fileLwIP/LwIP_HTTP_Server_Netconn_RTOS/Inc/lwipopts.h * @author MCD Application Team * @brief lwIP Options Configuration. ** * * This sort of explains the memory usage * https://lwip-users.nongnu.narkive.com/dkzkPa8l/lwip-memory-settings * https://www.cnblogs.com/shangdawei/p/3494148.html * https://lwip.fandom.com/wiki/Tuning_TCP * https://groups.google.com/g/osdeve_mirror_tcpip_lwip/c/lFYJ7Fw0Cxg * ST UM1713 document gives an overview of integrating all this. * * * * * 7/7/22 PH MEM_SIZE set to 5k (was 10k). Only ~1.5k is used. * 13/7/22 PH MEMP_MEM_MALLOC=1, MEM_SIZE=16k. * 14/7/22 PH MEMP_MEM_MALLOC=0; 1 was unreliable. 8 x 512 byte buffers now. * 6/8/22 PH 4 x MTU buffers for RX. Done partly for EditGetData(). * MEM_SIZE=6k. 5k is used - see .map file for ram_heap address. * Sizes of various static RAM structures determined experimentally. * * * * * * * */ #ifndef __LWIPOPTS_H__ #define __LWIPOPTS_H__ /** * NO_SYS==1: Provides VERY minimal functionality. Otherwise, * use lwIP facilities. */ #define NO_SYS 0 // Flag to make LWIP API thread-safe. The netconn and socket APIs are claimed // to be thread-safe anyway. The raw API is never thread-safe. #define LWIP_TCPIP_CORE_LOCKING 1 // This places more objects into the static block defined by MEM_SIZE. // Uses mem_malloc/mem_free instead of the lwip pool allocator. // MEM_SIZE now needs to be increased by about 10k. // It doesn't magically produce extra memory, and causes crashes. // There is also a performance loss, apparently. AVOID. #define MEMP_MEM_MALLOC 0 //NC: Need for sending PING messages by keepalive #define LWIP_RAW 1 #define DEFAULT_RAW_RECVMBOX_SIZE 4 /*-*/ /* LwIP Stack Parameters (modified compared to initialization value in opt.h) -*/ /* Parameters set in STM32CubeMX LwIP Configuration GUI -*/ /*- Value in opt.h for LWIP_DNS: 0 -*/ #define LWIP_DNS 1 /* -- Memory options -- */ /* MEM_ALIGNMENT: should be set to the alignment of the CPU for which lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2 byte alignment -> define MEM_ALIGNMENT to 2. */ #define MEM_ALIGNMENT 4 // MEM_SIZE: the size of the heap memory. This is a statically allocated block. You can find it // in the .map file as the symbol ram_heap and you can see how much of this RAM gets used. // If MEMP_MEM_MALLOC=0, this holds just the PBUF_ stuff. // If MEMP_MEM_MALLOC=1 (which is not reliable) this greatly expands and needs 16k+. // Empirically this needs to be big enough for at least 4 x PBUF_POOL_BUFSIZE. // 6k yields a good speed and going to 8k+ makes a minimal improvement. The main // factor affecting speed in the KDE is the poll period in ethernetif_input(). // This value also limits the biggest block size sent out by netconn_write. With the // MEM_SIZE of 6k, the biggest block netconn_write will send out is 4k. #define MEM_SIZE(6*1024) // MEMP_ structures. Their sizes have been determined experimentally, by // increasing them and seeing free RAM changing. /* MEMP_NUM_PBUF: the number of memp struct pbufs. If the application sends a lot of data out of ROM (or other static memory), this should be set high. */ #define MEMP_NUM_PBUF 5 // each 1 is 20 bytes of static RAM /* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One per active UDP "connection". */ #define MEMP_NUM_UDP_PCB6 // each 1 is 32 bytes of static RAM /* MEMP_NUM_TCP_PCB: the number of simultaneously active TCP connections. */ #define MEMP_NUM_TCP_PCB5 // each 1 is 145 bytes of static RAM /* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections. */ #define MEMP_NUM_TCP_PCB_LISTEN 5 // each 1 is 28 bytes of static RAM /*
[lwip-users] How to use LWIP from FreeRTOS tasks - a thread safety question
This has been solved. The various online examples which show mutexing of the low level input and output are using the same mutex which LWIP itself uses for protecting its API if LWIP_TCPIP_CORE_LOCKING=1. Obviously that will just hang! You have to use a different mutex for the low level I/O. But actually it seems clear that NO mutex is needed at the low level end anyway, because LWIP itself only ever makes a single threaded call to low_level_output. And low_level_input is just an RTOS task which runs in a loop by itself so that needs no protection. All this has been running for weeks now, multiple threads doing ETH activity, different outside servers, HTTP and TLS concurrently, 24/7. Last question is this: It has been claimed that: 1) The LWIP netconn and socket API is thread safe regardless of LWIP_TCPIP_CORE_LOCKING. The only benefit of LWIP_TCPIP_CORE_LOCKING=1 is that it also makes the RAW API thread safe also. 2) LWIP_TCPIP_CORE_LOCKING=1 is more efficient internally in LWIP if it is called from multiple RTOS tasks. I hae not been able to verify 1) or 2) and asking the claimants yielded silence. Lots of conflicting info online. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Sizes of lwip structures?
I have partly solved this question, by changing values and recompiling after each one, and posted it here https://www.eevblog.com/forum/microcontrollers/any-experts-on-lwip-and-the-netconn-api-(not-looking-for-free-can-pay)/msg4342318/#msg4342318 It's a pity this list is practically dead. It gets a lot of google hits, but almost nobody replies. I wonder if there is a document anywhere describing in a readable manner LWIP design. Well nobody is going to reply to that question, too :) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Any experts on LWIP and the netconn API? (not looking for free; can pay)
With help from others I have solved this issue and posted it here https://www.eevblog.com/forum/microcontrollers/any-experts-on-lwip-and-the-netconn-api-(not-looking-for-free-can-pay)/msg4341529/#msg4341529 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Any experts on LWIP and the netconn API? (not looking for free; can pay)
Hi All,
I am not sure this list is going anywhere but I will try anyway :)
I am implementing a simple web server. The code is all over the place.
It came with ST Cube IDE, and an identical version with same comments
is here
https://github.com/particle-iot/lwip/blob/master/contrib/apps/httpserver/httpserver-netconn.c
However, they assume incoming data (or the part of it of interest) is
contained in just the one buffer. The code is like this
> err_t res = netconn_recv(conn, );
> if ((res == ERR_OK) && (inbuf != NULL))
> {
>if (netconn_err(conn) == ERR_OK)
>{
> netbuf_data(inbuf, (void**), );
> /* Is this an HTTP GET command? (only check the first 5 chars, since
> there are other formats for GET, and we're keeping it very simple )*/
> if ((buflen >=5) && (strncmp(buf, "GET /", 5) == 0))
> {
netconn_recv appears to be a blocking function which tells you some
data has arrived.
netconn_err is a macro
netbuf_data reads in a buffer. There is no way to know how big this
buffer is, but you are told how much data is in there.
The problem I have is that I am extending this "server" (on which I
have spent at least a week full-time and which works solidly) with a
file upload feature, and that obviously involves getting a bit more
incoming data than just a few strings. There are almost no examples on
the web of using netconn for receiving a data stream of say 2MB.
I am wondering if the buffer pointed to by netbuf_data is actually one
of these, defined in lwipopts.h
>/* PBUF_POOL_SIZE: the number of buffers in the pbuf pool. */
>#define PBUF_POOL_SIZE 8
>
>/* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. */
>// If small, set it so that say 3 of them hold a complete largest packet
>(1500+stuff)
>#define PBUF_POOL_BUFSIZE512
which would mean no more than 512 bytes. It kind of makes sense since
all the netconn code refers to pbufs.
There is also netbuf_next and I don't know how it fits into this
scheme.
Basically I need some code which implements data receive, with a
timeout. The timeout I can do in various ways, with a FreeRTOS timer
being the most "modern" way. The buffer from which I will be writing
the eventual file is 512 bytes long. I can write less but can't write
more.
On a related topic, am I right in saying that if
LWIP_TCPIP_CORE_LOCKING=1
then the LWIP API is thread safe for raw, netconn and sockets, whereas
if
LWIP_TCPIP_CORE_LOCKING=0
then the LWIP API is thread safe for netconn and sockets only?
There is a vast range of disagreement online about this topic.
Thank you in advance for any comments.
Peter
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Performance issue: sending large buffers
Hello Vincenzo
Like me you will waste half your life trying to get answers. Almost
nobody replies on lwip etc issues...
I suggest you post your lwipopts file. Also the ETH buffer settings in
one of the .h files
uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE]
uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE]
And your ethernetif_input() and low_level_input() functions.
I have just spent a few days on this stuff and started with
100kbytes/sec and now can do 1200kbytes/sec albeit with more RAM for
buffers, so I traded it off at 250kbytes/sec. I think one could get
2000kbytes/sec if one didn't have other constraints and had interrupt
driven RX (168MHz 32F417).
I am also polling in ethernetif_input() which is sub-optimal but works
ok, and there are lots of other tasks running.
Note that there are many issues which arise if e.g. you want the LWIP
API thread-safe. You need LWIP_TCPIP_CORE_LOCKING=1 and then you need a
separate set of mutexes around the low level stuff.
// RTOS task; runs for ever
void ethernetif_input( void * argument )
{
struct pbuf *p;
struct netif *netif = (struct netif *) argument;
// This mutex position is based on an idea from Piranha here, with the
delay added
//
https://community.st.com/s/question/0D50XBOtUflSQF/bug-stm32-lwip-ethernet-driver-rx-deadlock
do
{
sys_mutex_lock(_eth_if_in);
p = low_level_input( netif );
sys_mutex_unlock(_eth_if_in);
if (p!=NULL)
{
if (netif->input( p, netif) != ERR_OK )
{
pbuf_free(p);
}
}
else
{
osDelay(10);
}
} while(true);
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Strange values appearing inside an LWIP packet buffer
Hi All,
Amazingly, I managed to catch one instance fairly quickly
https://peter-ftp.co.uk/screenshots/202207150014414908.jpg
The code is
> if ((!mem->used) &&
> (mem->next - (ptr + SIZEOF_STRUCT_MEM)) >= size) {
>/* mem is not used and at least perfect fit is possible:
> * mem->next - (ptr + SIZEOF_STRUCT_MEM) gives us the 'user data size'
> of mem */
>
>if (mem->next - (ptr + SIZEOF_STRUCT_MEM) >= (size + SIZEOF_STRUCT_MEM
> + MIN_SIZE_ALIGNED)) {
> /* (in addition to the above, we test if another struct mem
> (SIZEOF_STRUCT_MEM) containing
> * at least MIN_SIZE_ALIGNED of data also fits in the 'user data
> space' of 'mem')
> * -> split large block, create empty remainder,
> * remainder must be large enough to contain MIN_SIZE_ALIGNED data:
> if
> * mem->next - (ptr + (2*SIZEOF_STRUCT_MEM)) == size,
> * struct mem would fit in but no data between mem2 and mem2->next
> * @todo we could leave out MIN_SIZE_ALIGNED. We would create an
> empty
> * region that couldn't hold data, but when mem->next gets
> freed,
> * the 2 regions would be combined, resulting in more free
> memory
> */
> ptr2 = ptr + SIZEOF_STRUCT_MEM + size;
> /* create mem2 struct */
> mem2 = (struct mem *)(void *)[ptr2];
> mem2->used = 0;
> mem2->next = mem->next;
> mem2->prev = ptr;
so it looks genuine. It does suggest that the PBUFs are used for stuff
other than packet data. Some sort of struct is being filled-in.
Strange place for it though.
Peter
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Strange values appearing inside an LWIP packet buffer
Hi All, I am seeing these curious values in the LWIP buffers, PBUF_POOL_BUFSIZE. This is some distance after the packet data I would normally expect to see there. >0x20003770 > >0x20003790 > >0x200037B0 >08941800 >0x200037D0 08A01800 > .. . >0x200037F0 > >0x20003810 08E81800 >08F41800 ..è...ô. >0x20003830 > >0x20003850 > >0x20003870 > >0x20003890 > Little-endian so the bytes are 08 e8 18 00 and a uint32_t would be 0x0018e808 etc. The addresses move about which makes it hard to do a watchpoint but I managed to catch it once and the code was some heap code, so it looked possibly legitimate. My concern is stray pointers. Thank you in advance for any comments. Peter ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Sizes of lwip structures?
Hi All, Could someone tell me roughly how large these structures are? I have tried to vary each one by some large amount and then see how much RAM (prefilled with 0x00) gets overwritten after the system has been running for some time, but this is very hit and miss. This Q is in relation to how to establish MEM_SIZE. I can see that if MEMP_MEM_MALLOC=0 then it needs to be PBUF_POOL_SIZE*PBUF_POOL_BUFSIZE (currently 8x512=4k) plus all the MEMP_ structures. Currently I have MEM_SIZE=6k, and by reducing that gradually I have sort of established that less than 4*PBUF_POOL_BUFSIZE starts to break various things. /* MEMP_NUM_PBUF: the number of memp struct pbufs. If the application sends a lot of data out of ROM (or other static memory), this should be set high. */ #define MEMP_NUM_PBUF 5 //10 /* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One per active UDP "connection". */ #define MEMP_NUM_UDP_PCB6 /* MEMP_NUM_TCP_PCB: the number of simulatenously active TCP connections. */ #define MEMP_NUM_TCP_PCB5 //10 /* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections. */ #define MEMP_NUM_TCP_PCB_LISTEN 5 /* MEMP_NUM_TCP_SEG: the number of simultaneously queued TCP segments. */ #define MEMP_NUM_TCP_SEG8 /* MEMP_NUM_SYS_TIMEOUT: the number of simulateously active timeouts. */ #define MEMP_NUM_SYS_TIMEOUT10 Needless to say I have googled everywhere :) Thank you in advance, Peter ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip-users Digest, Vol 227, Issue 7
I have solved the LWIP_TCPIP_CORE_LOCKING=1 issue. Details here https://www.eevblog.com/forum/microcontrollers/any-stm-32f4-eth-lwip-freertos-mbedtls-experts-here-(not-free-advice)/msg4298761/#msg4298761 It was overlapping mutex regions, due to incorrect code in ethernetif.c. The MEMP_MEM_MALLOC=1 issue remains unresolved but I don't need it. It seems "neater" but is doesn't generate RAM from nowhere... Peter >Send lwip-users mailing list submissions to > lwip-users@nongnu.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/lwip-users >or, via email, send a message with subject or body 'help' to > lwip-users-requ...@nongnu.org > >You can reach the person managing the list at > lwip-users-ow...@nongnu.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of lwip-users digest..." > > >Today's Topics: > > 1. Re: How to use LWIP from FreeRTOS tasks - a thread safety > question (Peter) > 2. Re: How to use LWIP from FreeRTOS tasks - a thread safety > question (Jeffrey A. Wormsley) > > >------ > >Message: 1 >Date: Tue, 12 Jul 2022 17:17:22 +0100 >From: Peter >To: Dave Nadler >Cc: Mailing list for lwIP users >Subject: Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a > thread safety question >Message-ID: <202207121617.26cghns3094...@mail.authsmtp.com> >Content-Type: text/plain; charset=us-ascii > > > >>Hi Peter - Can you start at the beginning? >>Has this ever worked, or for 2 years it always crashed if you used LWIP? >>What exactly "crashes the whole thing"? >>You're aware of the numerous issues surrounding STM-provided Ethernet >>driver? >>Hope this helps, >>Best Regards, Dave > >I have spent more time on that LWIP_TCPIP_CORE_LOCKING=1 issue. >Tracing through the code, it does appear that eventually LWIP does end >up using FreeRTOS mutexes. > >It breaks something else however, and I can't easily trace it because >DHCP fails to work, and one can't really trace that because taking a >breakpoint causes timeouts etc. Also that code is too convoluted for >me to understand :) > >I have been trying to find advice around the place and this post >summarises my latest findings on this > >https://www.eevblog.com/forum/microcontrollers/lwip-32f417-how-to-optimise-network-stack-memory-allocation/msg4295431/#msg4295431 > > > >-- > >Message: 2 >Date: Tue, 12 Jul 2022 13:50:21 -0400 >From: "Jeffrey A. Wormsley" >To: Mailing list for lwIP users >Cc: Dave Nadler >Subject: Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a > thread safety question >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >No real help here, but that CMSIS layer is intended to let you write your >application to one API, then port it to multiple RTOSes or even full >desktop/server OSes, presumably without changes. And digging through that >code is always (read "never") fun. > >Jeff > >On Tue, Jul 12, 2022 at 12:18 PM Peter wrote: > >> >> >> >Hi Peter - Can you start at the beginning? >> >Has this ever worked, or for 2 years it always crashed if you used LWIP? >> >What exactly "crashes the whole thing"? >> >You're aware of the numerous issues surrounding STM-provided Ethernet >> >driver? >> >Hope this helps, >> >Best Regards, Dave >> >> I have spent more time on that LWIP_TCPIP_CORE_LOCKING=1 issue. >> Tracing through the code, it does appear that eventually LWIP does end >> up using FreeRTOS mutexes. >> >> It breaks something else however, and I can't easily trace it because >> DHCP fails to work, and one can't really trace that because taking a >> breakpoint causes timeouts etc. Also that code is too convoluted for >> me to understand :) >> >> I have been trying to find advice around the place and this post >> summarises my latest findings on this >> >> >> https://www.eevblog.com/forum/microcontrollers/lwip-32f417-how-to-optimise-network-stack-memory-allocation/msg4295431/#msg4295431 >> >> ___ >> lwip-users mailing list >> lwip-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> >-- next part -- >An HTML attachment was scrubbed... >URL: ><https://lists.nongnu.org/archive/html/lwip-users/attachments/20220712/e1a0f157/attachment.htm> > >-- > >Subject: Digest Footer > >___ >lwip-users mailing list >lwip-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/lwip-users > > >-- > >End of lwip-users Digest, Vol 227, Issue 7 >** ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip-users Digest, Vol 227, Issue 7
I've spent a day or two on this and found some interesting stuff.
It appears that the mem_ heap used in LWIP *is* already thread safe.
In say mem.c I see
/* protect the heap from concurrent access */
sys_mutex_lock(_mutex);
LWIP_MEM_ALLOC_PROTECT();
#if LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT
/* run as long as a mem_free disturbed mem_malloc or mem_trim */
do {
local_mem_free_count = 0;
#endif /* LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT */
/* Scan through the heap searching for a free block that is big
enough,
* beginning with the lowest free block.
*/
for (ptr = (mem_size_t)((u8_t *)lfree - ram); ptr <
MEM_SIZE_ALIGNED - size;
1st line above does a standard FreeRTOS mutex.
2nd line above is a macro which turns out to be empty but other
instances (not #defined in my project) end up calling the same mutex.
There is also a note that this can be implemented by disabling
interrupts.
So that (the LWIP heap) should be OK.
What I don't know about is whether the socket etc API is likewise
thread-safe. I traced a call to lwip_socket(). Then netconn_apimsg()
then tcpip_send_msg_wait_sem() and that contains
#if LWIP_TCPIP_CORE_LOCKING
LWIP_UNUSED_ARG(sem);
LOCK_TCPIP_CORE();
fn(apimsg);
UNLOCK_TCPIP_CORE();
return ERR_OK;
#else /* LWIP_TCPIP_CORE_LOCKING */
TCPIP_MSG_VAR_DECLARE(msg);
LWIP_ASSERT("semaphore not initialized", sys_sem_valid(sem));
LWIP_ASSERT("Invalid mbox", sys_mbox_valid_val(mbox));
TCPIP_MSG_VAR_ALLOC(msg);
TCPIP_MSG_VAR_REF(msg).type = TCPIP_MSG_API;
TCPIP_MSG_VAR_REF(msg).msg.api_msg.function = fn;
TCPIP_MSG_VAR_REF(msg).msg.api_msg.msg = apimsg;
sys_mbox_post(, _MSG_VAR_REF(msg));
sys_arch_sem_wait(sem, 0);
TCPIP_MSG_VAR_FREE(msg);
return ERR_OK;
#endif /* LWIP_TCPIP_CORE_LOCKING */
where the now famous LWIP_TCPIP_CORE_LOCKING is greyed-out (not
defined)!
If I set LWIP_TCPIP_CORE_LOCKING=1 then DHCP stops working and that
code is too complex for me to work out.
But it looks like this is the key. No way will this project work
without this, because I have 3 RTOS tasks doing socket calls.
Peter
>Send lwip-users mailing list submissions to
> lwip-users@nongnu.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>or, via email, send a message with subject or body 'help' to
> lwip-users-requ...@nongnu.org
>
>You can reach the person managing the list at
> lwip-users-ow...@nongnu.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of lwip-users digest..."
>
>
>Today's Topics:
>
> 1. Re: How to use LWIP from FreeRTOS tasks - a thread safety
> question (Peter)
> 2. Re: How to use LWIP from FreeRTOS tasks - a thread safety
> question (Jeffrey A. Wormsley)
>
>
>------
>
>Message: 1
>Date: Tue, 12 Jul 2022 17:17:22 +0100
>From: Peter
>To: Dave Nadler
>Cc: Mailing list for lwIP users
>Subject: Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a
> thread safety question
>Message-ID: <202207121617.26cghns3094...@mail.authsmtp.com>
>Content-Type: text/plain; charset=us-ascii
>
>
>
>>Hi Peter - Can you start at the beginning?
>>Has this ever worked, or for 2 years it always crashed if you used LWIP?
>>What exactly "crashes the whole thing"?
>>You're aware of the numerous issues surrounding STM-provided Ethernet
>>driver?
>>Hope this helps,
>>Best Regards, Dave
>
>I have spent more time on that LWIP_TCPIP_CORE_LOCKING=1 issue.
>Tracing through the code, it does appear that eventually LWIP does end
>up using FreeRTOS mutexes.
>
>It breaks something else however, and I can't easily trace it because
>DHCP fails to work, and one can't really trace that because taking a
>breakpoint causes timeouts etc. Also that code is too convoluted for
>me to understand :)
>
>I have been trying to find advice around the place and this post
>summarises my latest findings on this
>
>https://www.eevblog.com/forum/microcontrollers/lwip-32f417-how-to-optimise-network-stack-memory-allocation/msg4295431/#msg4295431
>
>
>
>--
>
>Message: 2
>Date: Tue, 12 Jul 2022 13:50:21 -0400
>From: "Jeffrey A. Wormsley"
>To: Mailing list for lwIP users
>Cc: Dave Nadler
>Subject: Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a
> thread safety question
>Message-ID:
>
>Content-Type: text/plain; charset="utf-8"
>
>No real help here, but that CMSIS layer is intended to let you write your
>application to one API, then port it to multiple RTOSes or even full
>desktop/server OSes, presumably wi
Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a thread safety question
>Hi Peter - Can you start at the beginning? >Has this ever worked, or for 2 years it always crashed if you used LWIP? >What exactly "crashes the whole thing"? >You're aware of the numerous issues surrounding STM-provided Ethernet >driver? >Hope this helps, >Best Regards, Dave I have spent more time on that LWIP_TCPIP_CORE_LOCKING=1 issue. Tracing through the code, it does appear that eventually LWIP does end up using FreeRTOS mutexes. It breaks something else however, and I can't easily trace it because DHCP fails to work, and one can't really trace that because taking a breakpoint causes timeouts etc. Also that code is too convoluted for me to understand :) I have been trying to find advice around the place and this post summarises my latest findings on this https://www.eevblog.com/forum/microcontrollers/lwip-32f417-how-to-optimise-network-stack-memory-allocation/msg4295431/#msg4295431 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a thread safety question
Hello Dave, Thanks for your reply. Yes it all works. I have just been tying up loose ends, partly as a result of writing the documentation for the project :) I've been doing embedded, mostly asm, since late 1970s (Z80 etc) and even wrote my own simple RTOS back then. I just didn't get into ethernet/IP etc until this project. So the ETH+LWIP+FreeRTOS+MbedTLS stuff was done by the "Monday guy" who has done this before (currently he is also doing an ESP32 project for somebody else and apparently everything just works on that because Espressif employed somebody on the forums who seemed to "know it all"). I got involved 1.5 years ago when it became clear that it would never get done otherwise. With an RTOS, one can avoid thread-safety issues by keeping all relevant stuff in one thread (and perhaps using messaging to enable other threads to access the resources) but this is a poor way to do things for the future so I have started digging around the thread safety issues. LWIP_TCPIP_CORE_LOCKING=1 does not actually crash the system. It just breaks something in getting the DHCP IP, which remains at 0. I will have to wait until next Monday for help :) Indeed ST code is buggy and the Monday guy spent a year or two of Mondays trawling the internet for the many patches. I have just seen this https://community.st.com/s/question/0D53W1Gi9BoSAJ/ethernet-hal-driver-reworked-by-st-and-available-in-22q1-preview-now-available-on-github and while it is probable that most relevant stuff there has already been implemented, we will review it at some point. As I said, the project runs well. It has DNS, DHCP, NTP, HTTP (simple server and client), HTTPS (MbedTLS client, single certificate only although I know there is a patch for processing a string of certs without needing enough RAM to hold them all), and we are communicating with other devices. So I think "enough has been patched" to do the job. This is my own small business. In a bigger corporate environment one would go berserk trying to work this way, but we don't have the money and a lot of open source software is like that. That UDP socket issue is probably something unrelated; what I find suspicious is that absolutely none of the values in lwipopts make the slightest difference. Closing that UDP socket removes the issue. The issue came to light only because there is one process which is a server and thus leaves the socket open (DNS and DHCP are clients and close their UDP sockets after use). My provisional hack is to detect HTTP server activity and set a flag which this UDP server task uses to close the socket, and it re-opens it on a timeout (the HTTP server is for occassional config use only so this is acceptable). It just concerns me that this could be hiding some other issue but all else seems to run ok. I have spent much time on general memory policy and especially FreeRTOS stacks. I have a graphical utility which shows the entire FreeRTOS memory block (64k, in the 32F417 CCM) and there no no stack issue. The lwipopts.h file follows. Regards, Peter >/** > > ** > * @fileLwIP/LwIP_HTTP_Server_Netconn_RTOS/Inc/lwipopts.h > * @author MCD Application Team > * @brief lwIP Options Configuration. > > ** >* >* This sort of explains the memory usage >* https://lwip-users.nongnu.narkive.com/dkzkPa8l/lwip-memory-settings >* https://www.cnblogs.com/shangdawei/p/3494148.html >* >* Receive data: >* This uses PBUF_POOL_SIZE (which is a number of buffers, each >PBUF_POOL_BUFSIZE in size). >* We dont need a whole lot of buffering here because the RX data is >polled, not >* interrupt-driven. This is deliberate, for simplicity and DOS >protection. This polling >* is done in ethernetif_input() which loops around all the time there is >RX data to be >* processed, and if there isnt, yielding to RTOS for 20ms. The PBUF size >is MTU+headers >* bytes, and with POOL_SIZE being 3, the RX queue can hold a max of 3 >packets regardless >* of their size. One could use a smaller PBUF size and then you end up >with more buffers >* if smaller packets are being sent, but most recommendations are to make >this a full >* MTU+headers. It is reasonable to assume that applications needing max >speed will be >* sending full size packets. How much of a bottleneck the polling is, >depends on how >* fast the host can send data to the KDE; if it can send packets solidly >then the 20ms >* yield will never be taken, otherwise this yield will slow it down a >bit. If this is an >* issue one could make the wait 10ms. However, low_level_input() uses >memcpy() to move >* the a
[lwip-users] How to use LWIP from FreeRTOS tasks - a thread safety question
Hi All, I am new here. I've been working on a ARM32 32F417 project for a couple of years. Someone else, working 1 day a week, implemented FreeRTOS, LWIP and MbedTLS and I am now revisiting these issues which I don't think were looked at in detail originally. Specifically I would like to know what LWIP settings are needed to achieve thread safety. For example I have one thread doing NTP (socket() call to get a UDP socket) and another thread doing a simple HTTP server (using the netconn API which seems to end up in the same "socket" API as the foregoing). Reading the vast number of mostly inconclusive posts on the internet, there appear to be two classes of API functions, and thread safety is more easily achieved if you restrict yourself to just one of these classes. But the advice is ambiguous. It looks like the implementer is required to provide a mutex set/reset function, although the need for this depends on which of the two above API sections one is using. I also appears that if you use just one class, the mutex is not necessary and just using the "critical section" macros (which basically just disable interrupts) is sufficient. OTOH a lot of online text says that LWIP is thread safe "out of the box" in some cases... I am using Cube IDE and have been stepping through the code but I am not much wiser. === The idea appears to have NO_SYS 0 LWIP_TCPIP_CORE_LOCKING 1 but that crashes the whole thing, presumably because nobody has implemented any of the above mentioned hooks. FreeRTOS can supply mutexes and these work very well. I use them all over the place. Looks like you have to implement these functions #define LWIP_MEM_FREE_PROTECT() sys_mutex_lock(_mutex) #define LWIP_MEM_FREE_UNPROTECT() sys_mutex_unlock(_mutex) There are what appear to be example functions in sys_arch.c under Mutexes. I find all this very confusing because e.g. here https://www.nongnu.org/lwip/2_0_x/pitfalls.html it states that In OS mode, Callback-style APIs AND Sequential-style APIs can be used. Sequential-style APIs are designed to be called from threads other than the TCPIP thread, so there is nothing to consider here. The implication is that these do not need mutex protection. And indeed stepping through code such as fd = socket(AF_INET, SOCK_DGRAM, 0); does find that a mutex is used, deep down. it calls conn = (struct netconn *)memp_malloc(MEMP_NETCONN); which does SYS_ARCH_PROTECT(old_level); but I can't see that defined anywhere so that is probably what needs to be done if you are setting LWIP_TCPIP_CORE_LOCKING 1 What I can't find anywhere is whether the "sequential" functions are thread-safe with or without LWIP_TCPIP_CORE_LOCKING. And where does SYS_ARCH_PROTECT come into all this, since it seems unrelated to LWIP_TCPIP_CORE_LOCKING. There is also a subtle issue which I am sure is unrelated to thread safety whereby if a single UDP socket is opened, it causes the HTTP server to be unable to transmit packets (lots of LWIP error counters++) when TLS is doing to crypto handshake (2-3 secs). This happens on the mere allocation of the UDP socket; no data being sent. Debugging this is too complicated because nobody I know knows where to look. It makes no difference what values one puts in the lwipopts.h file. I could post the file here but it would make a long post amd those tend to not produce replies :) Thank you in advance for any help. Peter ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] HTTPD speed with dynamic headers
Hi,
I am using Lwip 2.03 and "httpd.c" web server without rtos and I have a
problem with very slow download speed. My idea is to download whole
memory block of my device.
I create fsdata record like this:
const struct fsdata_file file__flash_bin[] =
{{
file__404_html,//next web page in list
(const unsigned char *)"/flash.bin",//name of this web page
(const unsigned char *)0x6000,//pointer do data
(64*1024*1024),//length of data
1,//1=HTTP included at begin of data, 0=use dynamic HTTP header
}};
With this setting, my download speed about 2.5MB/s. My processor NXP
IMXRT1062 is powerful. I expect speed to be closer to 100Mbit
(12.5MB/s)... Why it is only 2.5MS/s?
With fsdata above, HTTP header is missing at the begin of HTTP answer.
It is working well even without the header. But if I want to add HTTP
header, I have to enable "LWIP_HTTPD_DYNAMIC_HEADERS".
If I change fsdata record to this:
const struct fsdata_file file__flash_bin[] =
{{
file__404_html,//next web page in list
(const unsigned char *)"/flash.bin",//name of this web page
(const unsigned char *)0x6000,//pointer do data
(64*1024*1024),//length of data
0,//1=HTTP included at begin of data, 0=use dynamic HTTP header
}};
Then download speed in only 65KB/s.
What download speed have others Lwip web servers?
What is a options to speed up download from my Lwip web server?
Regards,
Peter
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] UDP server callback
Hello,
I created UDP server with LwIP stack on STM32F407. I tried example udp_echo
_server. It works.
Now I need send from server my own answer data in callback function.
The program hangs in callback function.
void udp_echoserver_receive_callback(void *arg, struct udp_pcb *upcb, struct
pbuf *p, const ip_addr_t *addr, u16_t port)
{
unsigned char buffer[80] = "my name is xxx";
p->payload = buffer;
p->len = p->tot_len = 20;
/* Connect to the remote client */
udp_connect(upcb, addr, UDP_CLIENT_PORT);
/* Tell the client that we have accepted it */
udp_send(upcb, p);
/* free the UDP connection, so we can accept new clients */
udp_disconnect(upcb);
/* Free the p buffer */
pbuf_free(p);
}
What is wrong ?
Is somewhere on web LwIP stack guide?
Thank you
Peter
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP spurious Retransmission and Dup Ack issue
Please don't send such utterly long attachments! This is a public mailinglist. Axel Lin wrote: > Hi, > I'm using netconn API. > While testing lwIPv2.0.1, I found my device seems stuck after running > for a couple minutes. > > My device running lwIP (192.168.0.103) as a tcp client. > A Linux laptop (192.168.0.104) running "netcat -l 8088" to receive data. > > In my use case, it's one-direction data transfer as lwIP device > sending data to the linux server. > After running for a couple minutes, I got a lot "TCP Spurious > Retransmission and TCP Dup ACK", > then the transfer stuck and abort in the end. > > Attached my wireshark log for reference. (I capture the log twice, the > same symptom) > > on log1, this issue begins from No. 44908. > on log2, this issue begins from No. 19090. > > Appreciate if someone can take a look at this. > > Thanks, > Axel > ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Embedded lwIP application stops working after 4-5 days
Hi Simon
Thank you for your response. I have inserted the assert, so hopefully it
will reveal something in the next 5 days or so.
Regards,
Peter.
Simon Goldschmidt skrev den 17.06.2016 12:52:
Peter Haagerup wrote:
the fields "max" and "err" in the MEM UDP_PCB section contains the
number 4294967295 (2^32 - 1) which is strange
That's really strange: 'err' is only increased but never decreased.
Also, by default, the stats counters are u16_t, not u32_t.
I don't expect disabling UDP to fix this problem...
Why don't you put an assert in memp.c where 'used' is decremented: just
add
"LWIP_ASSERT("double-free", lwip_stats.memp[type].used != 0);"
before
"MEMP_STATS_DEC(used, type);"
and you should be able to see if it really is an underflow.
Gisle Vanem wrote:
Just an idea, you could try:
#define LWIP_DNS_SECURE 0
Now I really don't see what this should change when using 1.4.1,
unless TI has backported a fix to their 1.4.1 (in which case it
wouldn't be 1.4.1 ...)
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Embedded lwIP application stops working after 4-5 days
Hi I am working on an embedded application in which I use lwIP to periodically send HTTP packets to a webserver (as TCP packets). It works fine for 4-5 days and then suddenly stops working. I have enabled lwIP stats in my lwipopts.h and it is outputting lwIP status to the UART. I captured this output to a file and also used Wireshark to capture the Ethernet traffic. In the lwIP log file, I see that around the time when it stops working, the fields "max" and "err" in the MEM UDP_PCB section contains the number 4294967295 (2^32 - 1) which is strange, since these fields are 0, 1 or 2 in the long period where there is no problems. This indicates to me that some kind of overflow is happening in the memory allocated to lwIP? Or could it be something else? In the Wireshark log, I can see that after my application is doing a HTTP POST, it usually gets a HTTP OK from the server as it is supposed to do. When things go wrong, this does not happen. After that, the router can no longer detect the microcontroller. I originally posted a similar question on the TI-E2E Community since I am using the Texas Instruments TM4C129XL LaunchPad Evaluation Kit (which is an ARM Cortex M4F based microcontroller with Ethernet PHY and other stuff on board). I got some responses to my question -- including the suggestion that I turn off UDP in lwipopts.h. I cannot do that, since I am using DHCP. This thread (http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/519748/1892060#1892060) appears to be dead now, which is why I am writing to this mailing list. By the way, I am using lwip-1.4.1 as supplied with TivaWare (TI's C library for the TM4C-series microcontrollers). So, I am hoping that an experienced lwIP user or lwIP developer can explain the meaning of "max" and "err" in the MEM UDP_PCB section and what could cause the strange values in these fields. Hopefully that could lead to a solution. Any help is very appreciated - thanks in advance :-) Regards, Peter Haagerup. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Mainline DHCP server?
Hello, is there a lwip mainline dhcp server? I found something, but I'm wondering why there is no dhcp server in the contrib repository. Would this be something to be added ? https://github.com/nekromant/esp8266-frankenstein/blob/master/src/lwip-app/dhcpserver.c https://github.com/nodemcu/nodemcu-firmware/blob/master/app/lwip/app/dhcpserver.c https://lists.gnu.org/archive/html/lwip-users/2012-12/msg00016.html do you know of other lwip related implemenatations? I have read about lwDHCP but this seems to be dead :( Mit freundlichen Grüßen / Best regards Peter Ruesch Research Scientist - Embedded Systems HELLA GUTMANN SOLUTIONS GMBH Am Krebsbach 2 79241 Ihringen, Germany Phone +49 (7668) 9900 - 1813 Fax +49 (7668) 9900 - 3923 www.hella-gutmann.com<http://www.hella-gutmann.com/> peter.rue...@hella-gutmann.com<mailto:peter.rue...@hella-gutmann.com> -- Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung * Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 * Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] illegal RTOS API call from ethernet receive interrupt
I'm relying on the ethernet driver Freescale provides for this board :( Are there any restrictions with using this driver? Can I still use the normal socket API? Does this kind of packet handling reduce performance? -- Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung * Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 * Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] illegal RTOS API call from ethernet receive interrupt
Hello, I’m doing some tests with lwip (1.4.1) and FreeRTOS (8.2.1) on a Kinetis K65 device. From the beginning was able to ping the target reliably. For some performance tests I added the lwiperf server from the mainline repo. I noticed, that if I was continuously pinging the target and ran a iperf test in parallel, the system stopped responding. When I halted the program execution, I was finding the program stuck in FreeRTOS runtime assertion triggered, (at least in understanding) because I was calling FreeRTOS API functions from within the Ethernet receive interrupt context. This (presumably) illegal call to the API function happens because of a mutex guarded malloc. This does not exactly seem wrong. But it leads to this “stuck in assertion” problem. I have uploaded the stacktrace as screenshot. http://postimg.org/image/bb94dm4nj/ if I alter the RTOS settings so that the assertion is not active anymore, I can run iperf and ping in parallel for hours. Why does this RTOS API function need to be called from within the receive interrupt? Best regards Peter ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] MUT setting with multiple netif
Hi, I have changed my subnet settings. ARP is still working but ICMP doesn't work anymore! I guess ARP is working thanks to my ethernetif_input implementation (Testing every netif). But I tought it was not necessary to check netif ip before to pass it to tcpip_input since it was done inside, was it? In this case I will have to search the right netif using netif_list before to pass it, right? Regards, Peter -- View this message in context: http://lwip.100.n7.nabble.com/MUT-setting-with-multiple-netif-tp21753p21757.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] MUT setting with multiple netif
Hi everybody, I am currently using multiple netif (2 or 3) for my HTTP server. But I am facing a problem, I cannot correctly set the MTU of the first netif I created. Let me explain: Netif 1: (first netif created, default netif) _mtu = 256 _ip= 192.168.10.2 Netif 2: (first netif created, default netif) _mtu = 578 = this size is for future DHCP test _ip= 192.168.10.3 I had to change my ethernet_input implementation concerning ARP reception but it's finnally correctly working. I am able to ping both netif1 and netif2. Moreover I can put my HTTP server listening either onto netif1 or netif2 then I can receive my HTTP web page by requesting @192.168.10.2 if it is the IP used and so on. But from my wireshark traces, I noticed it is always the mut of netif2 which is used. I tried to change, it is not the smallest it is always the netif2 imposing mtu. Maybe I am doing something wrong, hence any hints will be welcomed :) . Thanks, Peter -- View this message in context: http://lwip.100.n7.nabble.com/MUT-setting-with-multiple-netif-tp21753.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] MUT setting with multiple netif
Hi, Thanks for your quick response ! I agree this is not supposed to happen but it was nice since I had not to change my network chip settings each time I wanted to test one or another functionnality. Finaly I will set each netif on a different subnet. Regards, Peter -- View this message in context: http://lwip.100.n7.nabble.com/MUT-setting-with-multiple-netif-tp21753p21755.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Compiler warning
It's strange because I am using exactly the same release than you with the same paths (and I guess you use GCC as compiler ? ) but I don't get any warning. The only difference is our hierarchy but It should work since you precised entire dir in paths... I quickly checked and it is not a referenced bug. At the second point of this wiki you will find why I suggested you to change hierarchy but I am aware it is not an obligation and won't change anything. http://lwip.wikia.com/wiki/Using_lwIP_in_a_project http://lwip.wikia.com/wiki/Using_lwIP_in_a_project Regards, Peter -- View this message in context: http://lwip.100.n7.nabble.com/Compiler-warning-tp21733p21740.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwipopts.h, how to enlarge send and receive packet size
Hi, LP/李 wrote Is my comprehension above correct? No, I suggest you to read http://lwip.wikia.com/wiki/Lwipopts.h http://lwip.wikia.com/wiki/Lwipopts.h To resume it depend on which type of pbuf you alloc. For instance, in my case I am using pool-pbuf type, therefore two define are very important to me: _PBUF_POOL_SIZE - The number of pbuf present in the pool _PBUF_POOL_BUFSIZE - The size of each pbuf in this pool Hence I am able to receive: (PBUF_POOL_SIZE * PBUF_POOL_BUFSIZE) - (PBUF_POOL_SIZE * (PBUF_LINK_HLEN + PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN)) Bytes , and even more whether it is only one big packet since headers will just be present in the first pbuf of the chain... Note that this calculation should match your TCP window (look at your settings...) Regards, Peter -- View this message in context: http://lwip.100.n7.nabble.com/lwipopts-h-how-to-enlarge-send-and-receive-packet-size-tp21738p21741.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Compiler warning
Hi, Have you modified your compiler source paths? If it is just a warning it doesn't matter... The linker will do the job. But if you want to remove it then add right path to your compiler option or just include (#include ProjName/lwIP/include/ipv4/lwIP/ip.h) If you cannot compile it is probably due to IPv4-IPv6 conflict. And you will be able to solve this issue by removing either IPv4 or IPv6 source file. Or just exclude it if your using an IDE..). Regards, Peter -- View this message in context: http://lwip.100.n7.nabble.com/Compiler-warning-tp21733p21734.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Compiler warning
boisbu wrote Could you please highlight me where to add this include path? Is it directly in the lwip/src/api/tcpip.c file? Please remove your folder src. The right hierarchy (if I am right) is lwIP/api/tcpip.c . Do you see the difference? 1) Copy your entire src folder then copy it next to it (under lwIP folder), finally remove it. 2) Add to your include paths: -I $(LWIP_LIB_DIR)/include \ -I $(LWIP_LIB_DIR)/include\ipv4 \ -I $(LWIP_LIB_DIR)/netif\include \ -I $(LWIP_LIB_DIR)/lwIP_Apps \ - this one is optionnal 3) Everything should be ok but if the warning is still there then go at the top of tcpip.c and add : #include lwip/ip.h Regards, Peter -- View this message in context: http://lwip.100.n7.nabble.com/Compiler-warning-tp21733p21736.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] TCP sending without headers
Hi everybody, I have developed an HTTP server based on example supplied in contrib stable folder of latest lwIP release. My problem is my server reply after an HTTP request is just composed of data ! No headers from any layer whereas every others exchange are perfectly formed! /This is a screenshot of wireshark trace:/ http://lwip.100.n7.nabble.com/file/n21719/wire1.bmp /These are my settings from lwipopts.h :/ /*/ #define BYTE_ORDER LITTLE_ENDIAN #define XLWIP_CONFIG_INCLUDE_EMACLITE 1 #define TCPIP_THREAD_NAME tcpip #define LWIP_HTTPD_MAX_TAG_NAME_LEN 20 #define LWIP_HTTPD_MAX_TAG_INSERT_LEN 1500 #define TCPIP_THREAD_PRIO configLWIP_TASK_PRIORITY #define TCPIP_THREAD_STACKSIZE configTCPIP_TASK_STACK_SIZE #define DEFAULT_THREAD_STACKSIZE configDEFAULT_THREAD_STACKSIZE #define DEFAULT_TCP_RECVMBOX_SIZE 5 #define DEFAULT_UDP_RECVMBOX_SIZE 5 #define DEFAULT_ACCEPTMBOX_SIZE 5 #define TCPIP_MBOX_SIZE 10 #define NO_SYS 0 #define LWIP_SOCKET 1 #define LWIP_NETCONN 1 #define LWIP_SNMP0 #define LWIP_IGMP0 #define LWIP_ICMP1 #define LWIP_DNS 0 #define LWIP_HAVE_LOOPIF 0 #define TCP_LISTEN_BACKLOG 0 #define LWIP_SO_RCVTIMEO 1 #define LWIP_SO_RCVBUF 1 #define MEM_ALIGNMENT4 #define MEM_SIZE 5120 #define MEMP_NUM_PBUF10 #define LWIP_RAW 0 #define MEMP_NUM_RAW_PCB 2 #define MEMP_NUM_UDP_PCB 8 #define MEMP_NUM_TCP_PCB 8 #define MEMP_NUM_TCP_PCB_LISTEN 2 #define MEMP_NUM_TCP_SEG 8 #define MEMP_NUM_SYS_TIMEOUT10 #define MEMP_NUM_NETBUF 4 #define MEMP_NUM_NETCONN4 #define MEMP_NUM_TCPIP_MSG_API 4 #define MEMP_NUM_TCPIP_MSG_INPKT 4 #define MEMP_NUM_ARP_QUEUE 5 #define PBUF_POOL_SIZE 22 #define PBUF_POOL_BUFSIZE128+14+2 #define PBUF_LINK_HLEN 16 #define SYS_LIGHTWEIGHT_PROT(NO_SYS==0) #define LWIP_TCP 1 #define TCP_TTL 255 #define TCP_QUEUE_OOSEQ 0 #define TCP_MSS 88//1460//was 1460 but didn't work so I tried my real MSS which is MTU(128)-40 #define TCP_SND_BUF ( TCP_MSS * 2 ) #define TCP_SND_QUEUELEN (4 * TCP_SND_BUF/TCP_MSS) #define TCP_SNDLOWAT (TCP_SND_BUF/2) #define TCP_WND (PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - (PBUF_LINK_HLEN + PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN))) #define TCP_MAXRTX 12 #define TCP_SYNMAXRTX4 #define LWIP_ARP 1 #define ARP_TABLE_SIZE 10 #define ARP_QUEUEING 1 #define IP_FORWARD 0 #define IP_REASSEMBLY1 #define IP_REASS_MAX_PBUFS 10 #define MEMP_NUM_REASSDATA 10 #define IP_FRAG 0 #define ICMP_TTL 255 #define LWIP_DHCP0 #define DHCP_DOES_ARP_CHECK (LWIP_DHCP) #define LWIP_AUTOIP 0 #define LWIP_DHCP_AUTOIP_COOP (LWIP_DHCP LWIP_AUTOIP) #define LWIP_UDP 1 #define LWIP_UDPLITE 1 //Enable UDP Lite support for all API layers. #define UDP_TTL 255 // Thank you in advance for any advice, BR, PLM -- View this message in context: http://lwip.100.n7.nabble.com/TCP-sending-without-headers-tp21719.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP sending without headers
I am using netconn API (sorry I did not mentioned it), could I do the same? Is that a normal behaviour? Thank you. Peter -- View this message in context: http://lwip.100.n7.nabble.com/TCP-sending-without-headers-tp21719p21724.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP sending without headers
I read something about NOCOPY during netconn-write(), and in the contrib example the flag NOCOPY was used therefore I did the same. But It is correctl running with the flag NETCON_COPY instead of NETCONN_NOCOPY !! Obviously I would prefer to use NOCOPY since I only send read-only data with the view to improve execution time and memory usage... Any input will be welcome. Peter -- View this message in context: http://lwip.100.n7.nabble.com/TCP-sending-without-headers-tp21719p21727.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP sending without headers
Krzysztof Wesołowski wrote On Wed, Jul 10, 2013 at 1:58 PM, Peter LM lt; listmlm78@ gt; wrote: I read something about NOCOPY during netconn-write(), and in the contrib example the flag NOCOPY was used therefore I did the same. But It is correctl running with the flag NETCON_COPY instead of NETCONN_NOCOPY !! Obviously I would prefer to use NOCOPY since I only send read-only data with the view to improve execution time and memory usage... What you mean by read only data? It must be at least: - directly adressible (flash or RAM in MCU), - accesible by drivers DMA (for example Core Coupled RAM on STM32F4 cannot be used). Regards, Krzysztof Wesołowski ___ lwip-users mailing list lwip-users@ https://lists.nongnu.org/mailman/listinfo/lwip-users I meant read only data (const variable placed in .rodata section) thus directly adressible. I'm using only 128 KB RAM. I have not used DMA yet, just memcpy ... Regards, Peter -- View this message in context: http://lwip.100.n7.nabble.com/TCP-sending-without-headers-tp21719p21730.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] UDP reception problem
How stupid I am, I forgot to delete the netbuf after the UDP packet reception Thank you again, Peter -- View this message in context: http://lwip.100.n7.nabble.com/UDP-reception-problem-tp21624p21687.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] UDP reception problem
Hi, I have found my mistake. I was testing both UDP sending and receiving at the same time while not using a perfect matching socket (IP_ADDR_BROADCAST used as remote ip address instead of real one). Therefore it's working but after some exchanges my netconn doesn't fetch anything from the mailbox. Do you have any idea where it could be from? Thank you, Peter -- View this message in context: http://lwip.100.n7.nabble.com/UDP-reception-problem-tp21624p21674.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] UDP reception problem
Thank you for your response. For Raw UDP you were right ! It was a source port switching problem from my testing socket! Concerning Netconn UDP which I would like to use since my system is multi-thread, is there someone able to help me? Peter -- View this message in context: http://lwip.100.n7.nabble.com/UDP-reception-problem-tp21624p21659.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] UDP reception problem
Hi Everybody I am facing a problem concerning UDP reception. After have written my driver, I am currently testing it and things worked well until UDP test. Let me explain: _ARP is correctly running _ICMP is correctly running _IP is correctly running _UDP *broadcast sending* is correctly running through netconn API _UDP *reception* doesn't work at all through netconn API _UDP *reception* receives *one * packet through RAW API then crash at the second UDP request(ICMP not reachable sent) I am using the latest release of lwIP in multi-threading with FreeRTOS Could anybody help me? Note that I'm working on embedded system and don't have standard output... but these are my settings from lwipopts.h : /*/ #define BYTE_ORDER LITTLE_ENDIAN #define XLWIP_CONFIG_INCLUDE_EMACLITE 1 #define TCPIP_THREAD_NAME tcpip #define LWIP_HTTPD_MAX_TAG_NAME_LEN 20 #define LWIP_HTTPD_MAX_TAG_INSERT_LEN 1500 #define TCPIP_THREAD_PRIO configLWIP_TASK_PRIORITY #define TCPIP_THREAD_STACKSIZE configTCPIP_TASK_STACK_SIZE #define DEFAULT_THREAD_STACKSIZEconfigDEFAULT_THREAD_STACKSIZE #define DEFAULT_TCP_RECVMBOX_SIZE 5 #define DEFAULT_UDP_RECVMBOX_SIZE 5 #define DEFAULT_ACCEPTMBOX_SIZE 5 #define TCPIP_MBOX_SIZE 10 #define NO_SYS 0 #define LWIP_SOCKET 1 #define LWIP_NETCONN1 #define LWIP_SNMP 0 #define LWIP_IGMP 0 #define LWIP_ICMP 1 #define LWIP_DNS0 #define LWIP_HAVE_LOOPIF0 #define TCP_LISTEN_BACKLOG 0 #define LWIP_SO_RCVTIMEO1 #define LWIP_SO_RCVBUF 1 #undef LWIP_DEBUG #ifdef LWIP_DEBUG #define LWIP_DBG_MIN_LEVEL 0 #define PPP_DEBUG LWIP_DBG_OFF #define MEM_DEBUG LWIP_DBG_ON #define MEMP_DEBUG LWIP_DBG_ON #define PBUF_DEBUG LWIP_DBG_ON #define API_LIB_DEBUG LWIP_DBG_OFF #define API_MSG_DEBUG LWIP_DBG_OFF #define TCPIP_DEBUG LWIP_DBG_OFF #define NETIF_DEBUG LWIP_DBG_OFF #define SOCKETS_DEBUG LWIP_DBG_OFF #define DNS_DEBUG LWIP_DBG_OFF #define AUTOIP_DEBUGLWIP_DBG_OFF #define DHCP_DEBUG LWIP_DBG_OFF #define IP_DEBUGLWIP_DBG_OFF #define IP_REASS_DEBUG LWIP_DBG_OFF #define ICMP_DEBUG LWIP_DBG_OFF #define IGMP_DEBUG LWIP_DBG_OFF #define UDP_DEBUG LWIP_DBG_OFF #define TCP_DEBUG LWIP_DBG_OFF #define TCP_INPUT_DEBUG LWIP_DBG_OFF #define TCP_OUTPUT_DEBUGLWIP_DBG_OFF #define TCP_RTO_DEBUG LWIP_DBG_OFF #define TCP_CWND_DEBUG LWIP_DBG_OFF #define TCP_WND_DEBUG LWIP_DBG_OFF #define TCP_FR_DEBUGLWIP_DBG_OFF #define TCP_QLEN_DEBUG LWIP_DBG_OFF #define TCP_RST_DEBUG LWIP_DBG_OFF #endif #define LWIP_DBG_TYPES_ON (LWIP_DBG_ON|LWIP_DBG_TRACE|LWIP_DBG_STATE|LWIP_DBG_FRESH|LWIP_DBG_HALT) #define MEM_ALIGNMENT 4 #define MEM_SIZE5120 #define MEMP_NUM_PBUF 6 #define LWIP_RAW0 #define MEMP_NUM_RAW_PCB2 #define MEMP_NUM_UDP_PCB8 #define MEMP_NUM_TCP_PCB2 #define MEMP_NUM_TCP_PCB_LISTEN 2 #define MEMP_NUM_TCP_SEG8 #define MEMP_NUM_SYS_TIMEOUT10 #define MEMP_NUM_NETBUF 4 #define MEMP_NUM_NETCONN4 #define MEMP_NUM_TCPIP_MSG_API 4 #define MEMP_NUM_TCPIP_MSG_INPKT 4 #define MEMP_NUM_ARP_QUEUE 5 #define PBUF_POOL_SIZE 11 #define PBUF_POOL_BUFSIZE 375 #define PBUF_LINK_HLEN 16 #define
[lwip-users] serious lwIP 1.4.0 error
Hello, I am facing an serious error in lwIP 1.4.0. This might be fixed in lwIP 1.4.1, but I need a bugfix confirmation, because the lowlevel ethernet skeleton has been changed, and I only want to spend much time in the lowlevel driver porting, when this will fix my problem. The lwIP 1.4.0 problem is (I am using raw API), that lwIP gets a [FIN,ACK] from the other side (Firefox), but instead of doing a tcp_sent callback, it resubmits 3 times the packet that was already acked in the [FIN,ACK]. This leads to a hanging half-closed situation. Only after some minutes the Firefox on the PC will close the connection. Do you know if this has been fixed? Best Regards, Peter Sprenger - -- Moving Bytes Communications, Systementwicklung GmbH Geschäftsführer Peter Sprenger Carl-Sutor-Str.26 D-50226 Frechen Germany Registergericht: Amtsgericht Köln, HRB 30047 Ust-IDNr.: DE195140727 Tel.: +49/2234/9333-876 Fax.: +49/2234/9333-878 Email: spren...@moving-bytes.de http://www.moving-bytes.de ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] serious lwIP 1.4.0 error
Peter Sprenger spren...@moving-bytes.de wrote: The lwIP 1.4.0 problem is (I am using raw API), that lwIP gets a [FIN,ACK] from the other side (Firefox), but instead of doing a tcp_sent callback, it resubmits 3 times the packet that was already acked in the [FIN,ACK]. This leads to a hanging half-closed situation. Only after some minutes the Firefox on the PC will close the connection. Do you know if this has been fixed? Stupid question, but are you sure the FIN|ACK datagram actually reaches lwIP tcpip thread? You may be out of MEMP_NUM_TCPIP_MSG_INPKT. I ran into this a few times with similar symptoms - lwIP would retransmit data that looks ACKed if you only check the tcpdump trace. I am not sure. Since I use no RTOS NO_SYS is defined to 1 and then the MEMP_NUM_TCPIP_MSG_INPKT parameter is not used. What have I to change then? Best Regards, Peter Sprenger -uwe - -- Moving Bytes Communications, Systementwicklung GmbH Geschäftsführer Peter Sprenger Carl-Sutor-Str.26 D-50226 Frechen Germany Registergericht: Amtsgericht Köln, HRB 30047 Ust-IDNr.: DE195140727 Tel.: +49/2234/9333-876 Fax.: +49/2234/9333-878 Email: spren...@moving-bytes.de http://www.moving-bytes.de ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] lwip 1.3.2 waiting for ACK problem
Hi, I need some help. During developing lwip based firmware (without RTOS) I met problem with big image slow downloading speed. This problem is not new one, I saw many topics related to this issue, but all mentioned solutions seem not working on 1.3.2 version. So question is how to send more segments packets without waiting for ack. I have tried many ways to solve this problem but still no success. Changing memory settings allows to send bigger packets but this helps a little. Thanks for any help, Peter Pavlov Wireshark log: 16230 20802.761850 192.168.0.31 192.168.0.32 TCP 54 53584 http [ACK] Seq=356 Ack=103522 Win=65392 Len=0 16231 20802.771584 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16232 20802.771586 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16233 20802.971032 192.168.0.31 192.168.0.32 TCP 54 53584 http [ACK] Seq=356 Ack=104546 Win=65392 Len=0 16234 20802.979820 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16235 20802.979822 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16236 20803.171028 192.168.0.31 192.168.0.32 TCP 54 53584 http [ACK] Seq=356 Ack=105570 Win=65392 Len=0 16237 20803.179816 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16238 20803.179818 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16239 20803.261506 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16240 20803.261508 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16241 20803.261743 192.168.0.31 192.168.0.32 TCP 54 53584 http [ACK] Seq=356 Ack=107618 Win=65392 Len=0 16242 20803.271586 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16243 20803.271588 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16244 20803.471049 192.168.0.31 192.168.0.32 TCP 54 53584 http [ACK] Seq=356 Ack=108642 Win=65392 Len=0 16245 20803.479822 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16246 20803.479824 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16247 20803.680030 192.168.0.31 192.168.0.32 TCP 54 53584 http [ACK] Seq=356 Ack=109666 Win=65392 Len=0 16248 20803.688831 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16249 20803.688833 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16250 20803.761501 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] 16251 20803.761505 192.168.0.32 192.168.0.31 TCP 566[TCP segment of a reassembled PDU] ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip 1.3.2 waiting for ACK problem
I recorded communication between Firefox and controller with embedded http server (based on lwip). Controller IP 192.168.0.32 PC IP 192.168.0.31 Log 1.pcap shows part of communication when picture was loading in Firefox. As you can see lwip sends 2 or 4 packets with image segments fast and then waits for ack. Why only 2 or 4 can be sent? According my investigation problem relates to tcp_output(struct tcp_pcb *pcb) in tcp_out.c It would be great to play with number of segments to send before moment when ack is required. Peter Pavlov 1.pcap Description: Binary data lwipopts.h Description: Binary data ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] File transfer over TCP/IP
Dne 11.1.2012 12:49, Kieran Mansley napsal(a): On 11 Jan 2012, at 09:31, Simon Goldschmidt wrote: However, since µEZ v1.11 seems to contain lwIP 1.3.0, which is rather old, chances are that if this is really an lwIP bug, it is already fixed in 1.4.0. I agree. I do vaguely remember a bug like that where the out-of-order code wasn't correctly dealing with trimming of duplicate bytes, but can't remember enough details to say for sure that it was fixed. Easiest thing to do would be to upgrade. Or perhaps just turning off the out-of-order code in the version they've got would be enough to avoid the bug. Kieran ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users I defined #define TCP_QUEUE_OOSEQ 0 in file lwipopts.h and it works now. I will report this problem to uEZ developers. I hope that they will upgrade lwip version in uEZ as soon as possible. Thanks for help. Best regards Peter Jančo. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] File transfer over TCP/IP
Hi,
I write FTP server on LPC2478 and uEZ1.11 platform.
There is a simple loop where is recieving data from FTP client.
struct netbuf *inbuf;/
/
while(1)
{
inbuf = NULL;
inbuf = netconn_recv(conn_data);
if(inbuf)
{
netbuf_copy(inbuf,BlockBuffer,inbuf-ptr-tot_len);
UEZFileWrite(file,BlockBuffer,inbuf-ptr-tot_len,NULL);//store data to
filesystem
netbuf_delete(inbuf);
}
else
break;
}
FTP client (Total Commander) split the big file into few packets. For
example file with total length 9130B is split like this:
512B,988B,1460B,1460B,1460B,1460B,1460B,40B,290B
First 8 packets is received always fine. The last packet (290B) is
received just sometimes. So the received file have length only 8840B.
Connection timeout is set to 0 (infinite).
I have captured ethernet communication between FTP server (LPC2478) and
FTP client (my PC). LPC2478 don't recieve 290B packet at first attempt.
After that PC send retransmission with data length 330B. I don't
understand why. This is not the same packet which I lost. Data in this
packet is identical like in the 40B packet and 290B together. After them
is connection closed.
Why I have problem with receiving the last data packet?
Best regards Peter Janco.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] File transfer over TCP/IP
Dne 10.1.2012 21:13, Kieran Mansley napsal(a): On 10 Jan 2012, at 10:21, Peter Jančo wrote: LPC2478 don't recieve 290B packet at first attempt. After that PC send retransmission with data length 330B. I don't understand why. This is not the same packet which I lost. Data in this packet is identical like in the 40B packet and 290B together. After them is connection closed. It would be helpful to see the packet capture. It sounds like the PC is retransmitting the last two packets together, probably because it no longer needs to fragment them, and lwIP isn't acknowledging them or correctly passing the data to the application. Which version of lwIP are you using? Thanks Kieran I'm not sure which version is used. It is part of uEZ1.11 stack. In the lwIP sources is just year 2001-2004. Capture file for Ethereal is in the attachment. Best regards Peter Janco. ftp.cap Description: Binary data ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] HTTP server: sockets versus netconns
I'm using lwip to write an http server. Initially I was using the netconn API, but I'm trying to switch to the sockets API since I find it a bit less awkward. After this change, web clients now receive connection reset errors upon visiting a page. I've gotten it to work if the entire response is written in one lwip_send() call, but if for instance the header is written in a different call than the message body then the connection reset error occurs (I've checked this with a few browsers). I've checked using telnet to verify that identical data (at the payload level) is being received in either case. In other words sprintf(outbuf, response headerresponse body); lwip_send(sock, outbuf, strlen(outbuf), 0); lwip_close(sock); works as expected but sprintf(outbuf, response header); lwip_send(sock, outbuf, strlen(outbuf), 0); sprintf(outbuf, response body); lwip_send(sock, outbuf, strlen(outbuf), 0); lwip_close(sock); does not. It still triggers the error if the MSG_MORE flag is passed to the first lwip_send(), which I thought might help. Neither does a Connection: close field in the response header make any difference. What could be the issue here? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] lwIP reentrancy issues and TCP
I'm working on a basic TCP client using lwIP 1.32 on a TI LM3S6965 chip without an RTOS. Much is made of the fact that lwIP is non-reentrant, so you're supposed to have everything happen in the interrupt handler. OK, but how is a client that needs to transmit independently supposed to work? My TCP client often needs to send messages without receiving one. This means there isn't an incoming message to trigger an outgoing message. Outgoing messages can occur at any time when the client needs to send one. What is considered the correct code architecture for a TCP client that needs to transmit independently of received messages? It's no big deal to have the incoming TCP handled by the interrupt handler. I have even gone ahead and created a ring buffer that incoming messages are placed in. This lets the foreground code (non-interrupt code) pull messages from a shared buffer and deal with them. I want the foreground code to have time to handle messages and not bog down the interrupt response time. However, do I really have to do this for transmitting messages as well? Do I have to create a ring buffer, place outgoing messages in it, and have the systick timer used by lwIP check if there are new messages to send? This seems really inefficient for throughput. I was told on a different message thread that calling tcp_write from the foreground was a bad idea since it meant two threads (foreground and interrupt) were potentially in the TCP/IP stack at the same time. However, I have seen many (most? all?) examples of TCP code samples using this exact approach. This doesn't mean it's correct, but it is sure is confusing to keep seeing sample code like this. I have tried calling tcp_write from the foreground and it appears to work fine. However, I don't want to have it blow up later. Is lwIP really engineered so that the most logical situation (incoming TCP handled in the interrupt handler, tcp_write called from the foreground) is not allowed? Even with SYS_LIGHTWEIGHT_PROT set to 1 ? Shouldn't the lightweight protection be the kind of thing that handles this? If not, what are the situations that SYS_LIGHTWEIGHT_PROT handles? Thanks, PeterM ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP reentrancy issues and TCP
Simon, Sorry about new email vs. renamed email. I didn't realize the mailer was doing some hidden JuJu in the email headers. I was just re-subjecting a reply as a fast way to get the email address in the outgoing email. I'm a bit confused by your answer, so I have some more questions. You say that lwIP was designed to be run entirely from foreground (FG for short) code, with the Ethernet hardware interrupt handler merely setting a flag that the FG code polls. So the entire system was designed to be run in a polled mode? I guess this presupposes that the FG would never get stuck doing something that took a little too long, and fail to poll in a timely manner. That seems awfully hard to guarantee. You also say Stellaris is a bad example of an lwIP implementation. I wish that was noted loudly somewhere, as this is the first time I have heard this information. Clearly there are more people using lwIP on Stellaris than just me, so there must be solutions. Unfortunately, since you are the first person (and only that I've found so far) to state that lwIP for Stellaris is bad, I'm turning to you for help. Given that the Stellaris implementation is poor, what can I do to work within it? Since Stellaris has lwIP running completely in interrupts, what's the best way for me to get messages from the FG to lwIP's interrupt code? Thanks, PeterM On 6/24/2011 1:36 PM, Simon Goldschmidt wrote: First, please make sure you create a mail for a new thread instead of replying to an old mail and simply changing the subject: this confuses my mail app since it sorts by thread Id, not by subject. Peter Montgomerypjmo...@csi.com wrote: Is lwIP really engineered so that the most logical situation (incoming TCP handled in the interrupt handler, tcp_write called from the foreground) is not allowed? Yes, it is. (BTW, it might be the most logical situation to you, but that's not really an objective statement.) The reason for this is that the core lwIP code is only supposed to implement the networking code, not the interface to your hardware, OS, or timing requirements. Depending on whether lwIP is the highest priority software in your application or only low priority, you need to handle this differently. The original intention behind lwIP was to run without an OS and to let the Ethernet RX interrupt set a flag when new packets arrive. Then, the main loop has to check this flag and pull packets off the hardware, feeding them into the stack. This way, you may also call into the stack from the main code, as interrupts do not use lwIP. In this mode, timer functions are also executed from the main loop by checking a timer value, not from a timer ISR. Unfortunately, the stellaris code is a bad example here in that it calls into lwIP from interrupt level. This is confusing for lwIP beginners, since it can easily lead to concurrency problems when using lwIP from the main loop, too (or from other interrupt levels). Even with SYS_LIGHTWEIGHT_PROT set to 1 ? Shouldn't the lightweight protection be the kind of thing that handles this? If not, what are the situations that SYS_LIGHTWEIGHT_PROT handles? Currently, it provides concurrency protection for allocating and reallocating memory or pbufs only. By design, it cannot provide what you want: you would have to disable the interrupt while calling into lwIP to provide such kind of protection. To me, that's not LIGHTWEIGHT :-) Passing received packets into lwIP at interrupt level is generally only a good idea if you do need minimal latency between RX and TX. For all other scenarios, the original approach should be favored. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Writing a proxy server - how non-reentrant is lwip raw API?
Leon, Can I assume that I can call tcp_write from the mainline (not lwIP interrupt driven) code without problems? My app receives data TCP data using a ring buffer that the interrupt driven lwIP code fill, and which is read by mainline code. However, my mainline code does reply by directly calling tcp_write. It all seems to work, but I was hoping for clarification. Thanks, PeterM On 6/14/2011 6:36 PM, Leon Woestenberg wrote: Hello, On Wed, Jun 15, 2011 at 2:13 AM, wurzelwur...@thekeirs.com wrote: My question is, can I call tcp_write from within a tcp_recv callback? In this code, I've opened a pair of TCP pcbs and each one's state struct has a mate field that points to the other side's state struct to I can get its pcb. I think that's a very good question indeed, because we give no explicit guarantee in our documentation that this is guaranteed to work, AFAIK. A function is called reentrant if it can be interrupted and called again before previous calls complete execution. Now, as there are global variables in the stack, we cannot easily guarantee reentrancy, other than through code validation. snderr = tcp_write(rs-mate-mypcb, q-payload, q-len, 0); By the strictest definition of non-reentrant this might not be legal. On the other hand, this seems like a commonly-desired case, so I'm hoping it is expected to work? Yes, this should work. The tcp transmit code paths are cleanly seperated from the receive code paths through data structures. We should assume at the callback point the tcp state machine has those structures in valid state, valid enough to call into tcp_write(). Regards, ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] local_ip and remote_ip
Hi, I've been inspecting some lwip code, and to get IP addresses, i've noticed two variables for storing ip addresses: local_ip, and remote_ip. I was wondering whether anyone is able to tell me the difference between the two variables. Also, the lwip code i have is the code that came with Genode, which is an OS framework and as such, is likely to not be the latest version. Thanks Peter ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Requirements for the netconn or sockets APIs
This is basically a bunch of stupid questions due to not having had enough time to study the code base in detail, but here goes... I am looking at using lwip for an OS-less application. The application itself is a single-threaded client, but the event-driven model of the raw API (as far as I understand it) seems to match it poorly, so I have been investigating the netconn and sockets APIs. As far as I understand it, this requires multithreading, which isn't a problem -- a trivial thread scheduler is easy enough to implement. The question is, however, what capabilities that lwIP expects. In particular, the easiest form of scheduling is to have only two threads, the lwIP tcpip thread and the application thread, with the tcpip thread running with absolute priority. The tcpip thread would be woken up by interrupts (from the timer or the NIC) and by the application thread blocking. Can anyone think of any locking gotchas in this scenario? Similarly, what would be the simplest implementation of the necessary locking primitives that one can imagine? I don't know if simply enabling and disabling interrupts would be sufficient. -hpa ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] PPP, GPRS connection problem
Hi I plan to use lwIP to transmit GPS coordinates through GPRS on ARM architecture. I haven't found any gprs examples so I worte my mine for PC, but it doesn't work. I don't get answer to IPCP, Configure-Request messages. IPCP: timeout resending Config-Request state=6 (LS_REQSENT) After the timeout it resends 10 times and gives up. Here is my source code based on contrib 1.3.0: http://www.freeweb.hu/fodpeter/lwip/ppp_test.tar.gz I use an USB Wavecom modem and kubuntu 7.10. Perhaps you could try it or see the code, if i did just a dummy mistake. Or maybe somebody has a working example, that would be great too :) Thanks Peter Fodor ps: Here is my log (or here http://www.freeweb.hu/fodpeter/lwip/log.txt ) : tcp init done lcp_init: xmit_accm=0 0 0 0 Expecting: OK Expecting: CONNECT 115200 lcp_init: xmit_accm=0 0 0 0 pbuf_alloc(length=1504) pbuf_alloc(length=1504) == 0x806ef90 pppMain: unit 0: Connecting sio_read 4 bytes: 7E FF 7D 23 pppInProc[0]: got 4 bytes pppStartCB: unit 0 ppp_set_xaccm[0]: outACCM=0 0 0 0 ppp_send_config[0]: outACCM=FF FF FF FF ppp_recv_config[0]: inACCM=0 0 0 0 lcp_lowerup: asyncmap=0 0 0 0 LCP: lowerup state 0 (LS_INITIAL) - 2 (LS_CLOSED) auth_reset: 0 lcp_addci: L opt=2 0 lcp_addci: L opt=5 70A012B6 lcp_addci: opt=7 lcp_addci: opt=8 pbuf_alloc(length=0) pbuf_alloc: allocated pbuf 0x807586c pbuf_alloc(length=0) == 0x807586c pppWrite[0]: len=46 sio_write 46 bytes: 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 25 7D 26 70 A0 7D 32 B6 7D 27 7D 22 7D 28 7D 22 32 53 7E pbuf_free(0x807586c) pbuf_free: deallocating 0x807586c fsm_sdata(LCP): Sent code 1,1,20. LCP: sending Configure-Request, id 1 LCP: open state 2 (LS_CLOSED) - 6 (LS_REQSENT) waiting for ppp... sio_read 46 bytes: C0 21 7D 21 7D 21 7D 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7D 23 7D 24 C0 23 26 B4 7E pppInProc[0]: got 46 bytes pbuf_alloc(length=0) pbuf_alloc: allocated pbuf 0x807586c pbuf_alloc(length=0) == 0x807586c pppInput[0]: LCP len=22 fsm_input(LCP):1,1,22 fsm_rconfreq(LCP): Rcvd id 1 state=6 (LS_REQSENT) lcp_reqci: rcvd MRU 1500 ASYNCMAP=0 PCOMPRESSION ACCOMPRESSION PAP (C023) lcp_reqci: returning CONFACK. pbuf_alloc(length=0) pbuf_alloc: allocated pbuf 0x80757dc pbuf_alloc(length=0) == 0x80757dc pppWrite[0]: len=49 sio_write 49 bytes: FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7D 23 7D 24 C0 23 D0 47 7E pbuf_free(0x80757dc) pbuf_free: deallocating 0x80757dc fsm_sdata(LCP): Sent code 2,1,22. pbuf_free(0x807586c) pbuf_free: deallocating 0x807586c sio_read 1 bytes: 7E pppInProc[0]: got 1 bytes sio_read 25 bytes: FF 7D 23 C0 21 7D 24 7D 21 7D 20 7D 2A 7D 25 7D 26 70 A0 7D 32 B6 3C D8 7E pppInProc[0]: got 25 bytes pbuf_alloc(length=0) pbuf_alloc: allocated pbuf 0x807586c pbuf_alloc(length=0) == 0x807586c pppInput[0]: LCP len=10 fsm_input(LCP):4,1,10 fsm_rconfnakrej(LCP): Rcvd id 1 state=8 (LS_ACKSENT) lcp_rejci: long opt 5 rejected lcp_addci: L opt=2 0 lcp_addci: opt=7 lcp_addci: opt=8 pbuf_alloc(length=0) pbuf_alloc: allocated pbuf 0x80757dc pbuf_alloc(length=0) == 0x80757dc pppWrite[0]: len=36 sio_write 36 bytes: FF 7D 23 C0 21 7D 21 7D 22 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 87 3A 7E pbuf_free(0x80757dc) pbuf_free: deallocating 0x80757dc fsm_sdata(LCP): Sent code 1,2,14. LCP: sending Configure-Request, id 2 pbuf_free(0x807586c) pbuf_free: deallocating 0x807586c sio_read 37 bytes: 7E FF 7D 23 C0 21 7D 22 7D 22 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 B9 B9 7E pppInProc[0]: got 37 bytes pbuf_alloc(length=0) pbuf_alloc: allocated pbuf 0x807586c pbuf_alloc(length=0) == 0x807586c pppInput[0]: LCP len=14 fsm_input(LCP):2,2,14 fsm_rconfack(LCP): Rcvd id 2 state=8 (LS_ACKSENT) lcp_acki: Ack ppp_send_config[0]: outACCM=0 0 0 0 ppp_recv_config[0]: inACCM=0 0 0 0 link_established: 0 IPCP: lowerup state 0 (LS_INITIAL) - 2 (LS_CLOSED) pbuf_alloc(length=0) pbuf_alloc: allocated pbuf 0x80757dc pbuf_alloc(length=0) == 0x80757dc pppWrite[0]: len=29 sio_write 29 bytes: FF 03 80 21 01 01 00 16 03 06 00 00 00 00 81 06 00 00 00 00 83 06 00 00 00 00 6E DB 7E pbuf_free(0x80757dc) pbuf_free: deallocating 0x80757dc fsm_sdata(IPCP): Sent code 1,1,22. IPCP: sending Configure-Request, id 1 IPCP: open state 2 (LS_CLOSED) - 6 (LS_REQSENT) pbuf_free(0x807586c) pbuf_free: deallocating 0x807586c IPCP: timeout resending Config-Request state=6 (LS_REQSENT) main problem ... IPCP: timeout sending Config-Requests state=6 (LS_REQSENT) np_finished: 0 proto=21 link_down: 0 IPCP: lowerdown state 3 (LS_STOPPED) - 1 (LS_STARTING) IPCP: close reason=LCP down state 1 (LS_STARTING) - 0 (LS_INITIAL) pppLinkDown: unit 0 pppMainWakeup: unit 0 sio_read_abort: not yet implemented for unix ppp_send_config[0]: outACCM=FF FF FF FF ppp_recv_config[0]: inACCM=0 0 0 0 pbuf_alloc(length=0) pbuf_alloc: allocated pbuf
Re: [lwip-users] Required accuracy of timers
Jonathan Larmour wrote: In practice I don't think there are any timers which require better than 100ms granularity, and I doubt a little inaccuracy delaying a timeout by up to 55ms would really affect much (as long as it isn't up to 55ms _early_). Although in any case, PC hardware is actually pretty standard - with backward compatibility still present for obscenely ancient devices. Usually you can use the Periodic Interval Timer anywhere. You can see a usage example in eCos here(hal_pc_clock_initialize and hal_pc_clock_read): http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/hal/i386/pcmb/current/src/pcmb_misc.c?rev=1.9content-type=text/x-cvsweb-markupcvsroot=ecos with some info from: http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/hal/i386/pcmb/current/include/pcmb_intr.h?rev=1.5content-type=text/x-cvsweb-markupcvsroot=ecos It uses interrupt IRQ0 i.e. 32. IRQ 0 is INT 8 in the BIOS environment, not 32. And yes, PC hardware is pretty standard... but there isn't a whole lot of arbitration (who owns what resources) in the pre-OS environment. As such, you risk finding something else trying to play the same tricks. Once the OS boots, the OS is resource manager, and that particular problem doesn't exist in the same way. Sounds like 55 ms is adequate resolution, so doing more advanced PIT hackage is probably not necessary. -hpa ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] MAC Question????
K.J. Mansley wrote: On Wed, 2004-03-31 at 18:37, Kelly Chan wrote: Hello, We can use ARP to query MAC address for a particular IP? How about the other way such that is there any protocol or broadcast messages we can use to query IP address for a particular MAC address? Yes. Funnily enough it's called Reverse ARP (RARP): http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=rarpaction=Search Except RARP isn't really supported on most networks. It's really more of an early alternative to BOOTP (which then, in turn, got superceded by DHCP.) For a MAC address for an already configured host on the local network, one can send a ICMP ECHO (ping) packet with the appropriate unicast MAC address and the broadcast IP address. You should get a response back, at which time you know the MAC. -hpa ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Required accuracy of timers
Frédéric BERNON wrote: microseconds? Which ones? I thought most were in milliseconds. Which lwIP release do you use? Sorry, I might be mistaken. I'm looking at 1.3.0. Either way, the question still holds. -hpa ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Required accuracy of timers
lwip have a number of interfaces which are expected to return times in microseconds. How accurate does the underlying clock have to be to get decent performance (where decent is defined as 1 MB/s on a i686-class CPU?) For the purpose of my current application, I don't worry about multithreading of any sort. -hpa ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Bug in pbuf.c regarding PBUF_POOL
Leon wrote: I would certainly design a pre-emptive system by NOT entering the pbuf layer from interrupt context, but instead schedule a high-priority real-time task to move the packets of the chip from the interrupt handler, and nothing more. To have a pre-emptive multitasking system doesn't necessarily mean a high priority task is never interrupted by a lower priority one. In my case, higher priority just means that it gets more timeslices. (Unlike eCos where it wouldn't be interrupted by lower priority threads, at least with the standard scheduling behaviour). I am NOT sure if SYS_LIGHTWEIGHT_PROT protects against all concurrent acccess possible, In my case it certainly does, and I think it's generally meant to be. But it's several years ago that I dealt with this issue. I thought this was exactly the reason why it was called lightweight when introduced. I think not. It's lightweight, because it has very little overhead and is easy to implement (which makes it low-level, non-portabe and rigorous. Usually disabling all interrupts below a certain level.) All the best Peter ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Xilinx PowerPC receive udp messages
Hi Sathya,
thanks a lot, that example quite helped me.
But as I want to use the lwip in C++ I get an error at
XIntc_RegisterHandler(XPAR_OPB_INTC_0_BASEADDR,
XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR,
(XInterruptHandler)XEmac_IntrHandlerFifo,
xemacif_ptr-instance_ptr);
the error is: undefined reference to `XEmac_IntrHandlerFifo'
Even if I tell the C++ Compiler to handle this code as c code via
#ifdef __cplusplus
extern C { ...
I get this error. What am I doing wrong?
Regards,
Peter
Sathya Thammanur wrote:
Hi Peter,
Xilkernel is needed when you want to use the sockets API of lwIP. The
kernel
provides the semaphores and mailboxes feature required for the sockets
mode
operation. However, the RAW API works using callback functions. The code
definitely is different for Sockets mode vs Raw mode. Mixing the two modes
will not work correctly. A TCP echo server example using the RAW API mode
is
attached.
Hope this helps.
Sathya
On 8/21/06, Peter Kampmann [EMAIL PROTECTED]
wrote:
Hi everyone,
after trying various ways to receive an udp-packet to the powerPC, I want
to
ask if somebody of you sees perhaps the missing or wrong code that makes
my
code refusing to accept udp packages.
static u8_t my_timer = 0;
struct ip_addr ipaddr, netmask, gw;
char macAdress[6];
char port = 9050;
struct netif * networkInterface;
struct pbuf *pb;
int waiting_for_timer = 1;
XTime ml_base, ml_new, ml_offset;
extern XEmacIf_Config XEmacIf_ConfigTable[];
struct udp_pcb *pcb;
//init the lwip services
void init()
{
err_t err;
macAdress[0] = 0x00;
macAdress[1] = 0x0A;
macAdress[2] = 0x35;
macAdress[3] = 0x00;
macAdress[4] = 0x22;
macAdress[5] = 0x21;
//we need a timer
//init the lwip parts
sys_init();
mem_init();
xil_printf(heap initialised\r\n);
memp_init();
xil_printf(memp initialised\r\n);
pbuf_init();
xil_printf(pbuf init done\r\n);
xil_printf(Wait some time, for initialising\r\n);
unsigned int init_wait = 1500;
while(init_wait--);
//set the Hardware MAC-Address
xemacif_setmac(0,(u8_t *) macAdress );
//set up the ipAddress, Netmask and Gateway
IP4_ADDR(gw, 0,0,0,0);
IP4_ADDR(ipaddr, 192,168,1,1);
IP4_ADDR(netmask, 255,255,255,0);
//init netif
netif_init();
xil_printf(netif_init done\r\n);
ip_init();
//tcp_init();
udp_init();
//allocate memory for the netif
networkInterface = (netif*)mem_malloc(sizeof(struct netif));
//add a new network interface.
networkInterface = netif_add(networkInterface,
ipaddr,
netmask,
gw,
XEmacIf_ConfigTable[0],
xemacif_init,
ip_input);
xil_printf(wait for network to start...\r\n);
init_wait = 1500;
while(init_wait--);
netif_set_default(networkInterface);
xil_printf(Network started up!\r\n);
pcb = udp_new();
err = udp_bind(pcb, IP_ADDR_ANY, port);
//err = udp_bind(pcb, ipaddr, port);
if (err == ERR_OK)
{
xil_printf(NOTICE, Successfuly bound to port\r\n);
}
else
{
xil_printf(ERROR, Could not bound to port\r\n);
}
}
void echo_udp_init(void)
{
struct udp_pcb *pcb;
pcb = udp_new();
udp_bind( pcb, IP_ADDR_ANY, port );
udp_recv( pcb, echo_udp_recv, NULL );
}
static void echo_udp_recv( void* arg, struct udp_pcb *pcb, struct pbuf
*p,
struct ip_addr *addr, u16_t port )
{
xil_printf(receive...\r\n);
err_t err;
err = udp_connect( pcb, addr, port );
if (err != ERR_OK)
{
printf( ERROR: udp_connect() error: %d\n, err );
}
err = udp_send( pcb, p );
if (err != ERR_OK)
{
printf( ERROR: udp_send() error: %d\n, err );
}
pbuf_free( p );
udp_remove( pcb );
echo_udp_init();
return;
}
int main()
{
init();
echo_udp_init();
// Get the current Time-Base Register Value
//offset it by ml_offset
XTime_SetTime(0);
XTime_GetTime(ml_base);
ml_base += ml_offset;
while (1) {
while (waiting_for_timer) {
xemacif_input(networkInterface);
XTime_GetTime
[lwip-users] Xilinx PowerPC receive udp messages
Hi everyone,
after trying various ways to receive an udp-packet to the powerPC, I want to
ask if somebody of you sees perhaps the missing or wrong code that makes my
code refusing to accept udp packages.
static u8_t my_timer = 0;
struct ip_addr ipaddr, netmask, gw;
char macAdress[6];
char port = 9050;
struct netif * networkInterface;
struct pbuf *pb;
int waiting_for_timer = 1;
XTime ml_base, ml_new, ml_offset;
extern XEmacIf_Config XEmacIf_ConfigTable[];
struct udp_pcb *pcb;
//init the lwip services
void init()
{
err_t err;
macAdress[0] = 0x00;
macAdress[1] = 0x0A;
macAdress[2] = 0x35;
macAdress[3] = 0x00;
macAdress[4] = 0x22;
macAdress[5] = 0x21;
//we need a timer
//init the lwip parts
sys_init();
mem_init();
xil_printf(heap initialised\r\n);
memp_init();
xil_printf(memp initialised\r\n);
pbuf_init();
xil_printf(pbuf init done\r\n);
xil_printf(Wait some time, for initialising\r\n);
unsigned int init_wait = 1500;
while(init_wait--);
//set the Hardware MAC-Address
xemacif_setmac(0,(u8_t *) macAdress );
//set up the ipAddress, Netmask and Gateway
IP4_ADDR(gw, 0,0,0,0);
IP4_ADDR(ipaddr, 192,168,1,1);
IP4_ADDR(netmask, 255,255,255,0);
//init netif
netif_init();
xil_printf(netif_init done\r\n);
ip_init();
//tcp_init();
udp_init();
//allocate memory for the netif
networkInterface = (netif*)mem_malloc(sizeof(struct netif));
//add a new network interface.
networkInterface = netif_add(networkInterface,
ipaddr,
netmask,
gw,
XEmacIf_ConfigTable[0],
xemacif_init,
ip_input);
xil_printf(wait for network to start...\r\n);
init_wait = 1500;
while(init_wait--);
netif_set_default(networkInterface);
xil_printf(Network started up!\r\n);
pcb = udp_new();
err = udp_bind(pcb, IP_ADDR_ANY, port);
//err = udp_bind(pcb, ipaddr, port);
if (err == ERR_OK)
{
xil_printf(NOTICE, Successfuly bound to port\r\n);
}
else
{
xil_printf(ERROR, Could not bound to port\r\n);
}
}
void echo_udp_init(void)
{
struct udp_pcb *pcb;
pcb = udp_new();
udp_bind( pcb, IP_ADDR_ANY, port );
udp_recv( pcb, echo_udp_recv, NULL );
}
static void echo_udp_recv( void* arg, struct udp_pcb *pcb, struct pbuf *p,
struct ip_addr *addr, u16_t port )
{
xil_printf(receive...\r\n);
err_t err;
err = udp_connect( pcb, addr, port );
if (err != ERR_OK)
{
printf( ERROR: udp_connect() error: %d\n, err );
}
err = udp_send( pcb, p );
if (err != ERR_OK)
{
printf( ERROR: udp_send() error: %d\n, err );
}
pbuf_free( p );
udp_remove( pcb );
echo_udp_init();
return;
}
int main()
{
init();
echo_udp_init();
// Get the current Time-Base Register Value
//offset it by ml_offset
XTime_SetTime(0);
XTime_GetTime(ml_base);
ml_base += ml_offset;
while (1) {
while (waiting_for_timer) {
xemacif_input(networkInterface);
XTime_GetTime(ml_new);
if ( ml_new = ml_base ) {
waiting_for_timer = 0;
ml_base = ml_new + ml_offset;
}
}
// Call my_tmr() every ml_offset cycles
my_tmr();
waiting_for_timer = 1;
}
return(1);
}
As far as I understand the raw API, after calling the function
echo_udp_init()
the function echo_udp_recv is registered as a callback function, when a udp
package arrives, the function is then called automatically.
Instead of registering the callback function like udp_recv( pcb,
echo_udp_recv, NULL ); I tried also udp_recv( pcb, echo_udp_recv,
networkInterface );
But that didn't work, too.
Does this code not work in the stand-alone version? Do I need to use the
xilkernel?
Hope somebody can help me.
Thanks and regards,
Peter
--
View this message in context:
http://www.nabble.com/Xilinx-PowerPC-receive-udp-messages-tf2138912.html#a5902800
Sent from the lwip-users forum at Nabble.com
Re: [lwip-users] LWIP - Microblaze
Hello, is this issue already fixed? I get the same failure message: contrib/ports/v2pro/netif/xemacif.c:340: error: void value not ignored as it ought to be contrib/ports/v2pro/netif/xemacif.c:345: error: void value not ignored as it ought to be I am using the latest LWIP CVS-checkout on a PowerPC with the rawAPI and the StandAlone Configuration. Peter -- View this message in context: http://www.nabble.com/LWIP--%3E-Microblaze-tf1510871.html#a5681279 Sent from the lwip-users forum at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] LWIP - PowerPC
Hi everyone, i have the following problem: After checking out the newest version of the lwip library and the contrib-folder Xilinx Platform Studio complains, that there is a file missing: ./src/contrib/ports/v2pro/netif/xemacif_polled.c: no such file or directory Obiously in older versions, this file has been in the directory and is not needed any more. When i copy the missing file back into the folder, I get the following error while compiling: powerpc-eabi-gcc -O2 -c -g -Wall -gdwarf-2 -DIPv4 -msdata=eabi -mcpu=403 -I./lwip/src/include -I./lwip/src/include/ipv4 -I./contrib/ports/v2pro -I./contrib/ports/v2pro/include -I../../../include -c contrib/ports/v2pro/netif/xemacif.c contrib/ports/v2pro/netif/xemacif.c: In function `low_level_output': contrib/ports/v2pro/netif/xemacif.c:178: warning: implicit declaration of function `xil_printf' contrib/ports/v2pro/netif/xemacif.c: In function `xemacif_output': contrib/ports/v2pro/netif/xemacif.c:305: warning: assignment makes pointer from integer without a cast contrib/ports/v2pro/netif/xemacif.c: At top level: contrib/ports/v2pro/netif/xemacif.c:324: error: conflicting types for 'xemacif_input' ./contrib/ports/v2pro/include/netif/xemacif.h:44: error: previous declaration of 'xemacif_input' was here contrib/ports/v2pro/netif/xemacif.c:324: error: conflicting types for 'xemacif_input' ./contrib/ports/v2pro/include/netif/xemacif.h:44: error: previous declaration of 'xemacif_input' was here contrib/ports/v2pro/netif/xemacif.c: In function `xemacif_input': contrib/ports/v2pro/netif/xemacif.c:340: error: void value not ignored as it ought to be contrib/ports/v2pro/netif/xemacif.c:345: error: void value not ignored as it ought to be contrib/ports/v2pro/netif/xemacif.c:358: warning: `return' with a value, in function returning void The last two errors seem similar to the errors described in: http://www.nabble.com/LWIP--%3E-Microblaze-tf1510871.html#a4106067 So ist that the same problem or am I doing something wrong? Many Thanks, Peter Kampmann -- View this message in context: http://www.nabble.com/LWIP--%3E-PowerPC-tf2062546.html#a5681870 Sent from the lwip-users forum at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] sys_timeout
Hi Curt, I see what you and Derek are getting at, with sys_timeout being used only by lwip and i/f threads. But I still fail to see why it should be in src/core instead of cleanly separated, and implemented this way especially if it results in inelegant code and common misunderstandings. As long as one uses the given interfaces, and doesn't deal with the internals, there is little misunderstanding here. I would not propose a re-structuring of the code because there is little benefit and a risk of breaking essentials, especially the common usage of lwIP for both multitasking and RAW API. Suppose I want to implement timeouts using a hardware timer interrupt? Or suppose I want them to be handled by a separate thread? Or suppose I want to implement them as a setitimer and SIGALRM? I'm out of luck? You just don't implement the timeouts, you implement semaphores with timeout as required by lwIP. This is the given interface for a multitasking O/S, and nobody keeps you from implementing them with whatever means you like. I'm actually not using tcpip_thread() or any of the src/api, but rather the raw API (I'm precluded from using netconn since its message passing is based on shared memory). My O/S also does not have semaphores. It has nothing but timer interrupts, network interface interrupts, and bus interrupts. I define NO_SYS. From your previous postings, e.g. about semaphores, I concluded that you intend to use the multitasking API. The RAW API is a totally different issue. Peter ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] sys_timeout
Hi Curt, I'm actually not using tcpip_thread() or any of the src/api, but rather the raw API (I'm precluded from using netconn since its message passing is based on shared memory). My O/S also does not have semaphores. It has nothing but timer interrupts, network interface interrupts, and bus interrupts. I define NO_SYS. Just in case it's helpful: Are you sure you really don't have shared memory, in it's most trivial meaning? You seem to have a rudimentary O/S which makes it unlikely that memory protection is active. The point may be if your O/S supports multiple threads. If it does, you might even implement semaphores yourself, and use the multitasking API of lwIP. Peter ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] sys_timeout
Hi Curt, I think it's an architectural deficiency that any of sys_arch is implemented in the lwip core. I found it a benefit. Peter, To be clear: I'm not denigrating the idea of sys_arch, which is a typical example of a system abstraction layer and is critical for portability. All of the API definitions it provides are fine. However, sys_arch is not doing its job. It needs to be a clean layer between lwip and the underlying operating system, but instead it's inextricably tangled into lwip. For portability, it should be possible to completely replace the implementation of that layer. But portability to what? If an OS can not provide the requirements lwIP has now, I can not see how it'll meet what is required for a multitasking networking implementation anyway. No part of sys_arch belongs in lwip core. All of the sys_arch implementations should reside fully in the contrib platform ports. To wit, half of sys_arch is implemented in one particular way (core/sys.c), severely limiting what can be done to port the other half. What about those portions of code that are thought to be common across *all* platforms? First, there are none, as the troubling examples below will illustrate. Second, as you noted, in a proper multitasking O/S it is an easy matter to map each call. Third, even if there is common code between some of the ports, that's no reason to put it in lwip core instead of contrib. My operating system has its own perfectly good timeout function. However, I'm unable to use it because the core of lwip depends (incorrectly) on specific internal functionality of sys_timeout. If I were able to provide my own sys_timeout, I would be fine. If your multitasking O/S has just semaphores with timeouts and shared memory, you _are_ fine. In my case, I didn't even have semaphores in the OS, just timeouts, and I implemented the semaphores with timeouts myself. The mere existence of the pseudo-API calls sys_timeouts(), sys_arch_sem_wait() and sys_arch_mbox_fetch() provide further evidence that something is broken. These calls are unclean and should not be necessary. They are not broken (at least not in the somewhat older version I'm using). The internal mechanism is just a bit hard to understand and not elegant at some points. But someone who just wants to port lwIP doesn't need to care. Worse, any application that wants to use lwip is forced to be based on lwip's sys_arch primitives. If lwIP is intialized and the main+tcp+interface threads are active (this can be set up outside the application), the application just has to link itself into lwIP's thread list once. Afterwards it is free to call the lwIP networking API(s) or not, but it's not required to use the sys_arch primitives. The latter is not a true statement. Say your O/S has its own semaphore wait, which nearly all do. Your application can never call it instead of the sys_arch version, or sys_timeouts will cease. I guess this is a misunderstanding which comes up here every now and then. If your thread calls the semaphore wait of the OS directly, it is already implicitely sure that _this_ thread doesn't have timeouts in lwIPs list. (It could only have timeouts in the list if a blocking call into lwIP's API was ongoing in it's own context). The timeouts of the other threads are not affected if this thread uses the OS's mechanisms in parallel (unless the OS is broken). This forces your whole application to be rewritten based on sys_arch. No :-) I have several applications running fine, none was rewritten except for the networking calls and a startup function which makes sure that lwIP is up and I link my thread(s) in it's list. That is unreasonable, and in my (large) application, not possible. If sys_arch is properly separated out, this would no longer be a problem. If it was separated out, the risk of misunderstandings and erratic architecure layers rises. This could cause maintainance problems. All thge best Peter ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] PPP and HTTP on M16C
Hello, I'm looking for a tcp-stack with ppp and http protocols over serial line for the M16C. Has anybody already used lwip for this purpose and what is your experience? Does it work out of the box, or is there much work to do? Thanks in advance for your advice! Greetings, Peter -- http://pmrb.free.fr/contact/ ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP behaviour with Zero Copy API using Raw API interface
Hi again, To correct myself. It's not when there is an odd number of bytes to transfer that it fails. It fails when the data is located at an odd address. But as said before my workaround is to set copy to 1 and then it works OK. My target cpu is ARM and I've set MEM_ALIGNMENT to 4. //Peter On 6/8/05, Peter Jolasson [EMAIL PROTECTED] wrote: Hi, I dont have a solution to your problem but I can describe a 'funny' behavior that I've noticed with tcp_write(). When I send an even number of bytes I can set copy to 0. But when sending an odd number of bytes I must set copy to 1 otherwise it will fail. I'm using lwIP 1.1.0 //Peter On 6/7/05, Sathya Thammanur [EMAIL PROTECTED] wrote: Hi all, I have a client program that connects to a server on PC. The client is a simple program that sends data to PC. What I notice is that when I call tcp_write() with copy argument 1, then my program works without any issues. However, if I change copy to 0 then I notice that the TCP connection is not established completely. The following happens : ClientServer SYN -- - SYN, ACK Junk packet sent from client. The Server resends the SYN, ACK and then closes the connection. TCP client sends a lost ACK with incorrect sequence number after couple of junk packets. I do notice that my application call back that is registered with tcp_connected() is called. Here is where I start to send data. I am using lwip version 0.7.2. Am I using the tcp_write() in the right way as intended ? Any correct usage of this function will be very useful. Any help would be greatly appreciated. Thanks, Sathya ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP behaviour with Zero Copy API using Raw API interface
Hi,
My problem was the lwip_standard_chksum() routine in the inet.c module.
I wasn't aware that it might need to be rewritten/ported. (I don't
remember seeing it in any documentation.)
I just included a compile directive when MEM_ALIGNMENT = 2.
Maybe this could/should be put into the code repository?
//Peter
static u16_t
lwip_standard_chksum(void *dataptr, int len)
{
u32_t acc;
LWIP_DEBUGF(INET_DEBUG, (lwip_chksum(%p, %d)\n, (void *)dataptr, len));
for(acc = 0; len 1; len -= 2) {
/*acc = acc + *((u16_t *)dataptr)++;*/
#if MEM_ALIGNMENT = 2
acc += htons( ((u16_t)(((u8_t *)dataptr)[0])8) | ((u8_t *)dataptr)[1] );
dataptr += 2;
#else
acc += *(u16_t *)dataptr;
dataptr = (void *)((u16_t *)dataptr + 1);
#endif
}
/* add up any odd byte */
if (len == 1) {
acc += htons((u16_t)((*(u8_t *)dataptr) 0xff) 8);
LWIP_DEBUGF(INET_DEBUG, (inet: chksum: odd byte %d\n, (unsigned
int)(*(u8_t *)dataptr)));
} else {
LWIP_DEBUGF(INET_DEBUG, (inet: chksum: no odd byte\n));
}
acc = (acc 16) + (acc 0xUL);
if ((acc 0x) != 0) {
acc = (acc 16) + (acc 0xUL);
}
return (u16_t)acc;
}
On 6/8/05, Bill Knight [EMAIL PROTECTED] wrote:
This is possibly a problem with the ip checksum routine running
on a 16 or 32 bit cpu.
Regards
-Bill Knight
R O SOftWare
http://www.theARMPatch.com
On Wed, 8 Jun 2005 10:46:29 +0200, Peter Jolasson wrote:
Hi again,
To correct myself.
It's not when there is an odd number of bytes to transfer that it fails.
It fails when the data is located at an odd address.
But as said before my workaround is to set copy to 1 and then it works OK.
My target cpu is ARM and I've set MEM_ALIGNMENT to 4.
//Peter
On 6/8/05, Peter Jolasson [EMAIL PROTECTED] wrote:
Hi,
I dont have a solution to your problem but I can describe a 'funny'
behavior
that I've noticed with tcp_write().
When I send an even number of bytes I can set copy to 0.
But when sending an odd number of bytes I must set copy to 1 otherwise
it will fail.
I'm using lwIP 1.1.0
//Peter
On 6/7/05, Sathya Thammanur [EMAIL PROTECTED] wrote:
Hi all,
I have a client program that connects to a server on PC. The client is
a simple program that sends data to PC. What I notice is that when I
call tcp_write() with copy argument 1, then my program works
without any issues. However, if I change copy to 0 then I notice
that the TCP connection is not established completely. The following
happens :
ClientServer
SYN --
- SYN, ACK
Junk packet sent from client. The Server resends the SYN, ACK and then
closes the connection. TCP client sends a lost ACK with incorrect
sequence number after couple of junk packets.
I do notice that my application call back that is registered with
tcp_connected() is called. Here is where I start to send data. I am
using lwip version 0.7.2. Am I using the tcp_write() in the right way
as intended ? Any correct usage of this function will be very useful.
Any help would be greatly appreciated.
Thanks,
Sathya
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
