Re: [lwip-users] R: Re: lwip-users Digest, Vol 198, Issue 3

Please do not reply to digest mails. That breaks email threading for sure and you risk people lose track of your story. Regards, Simon Am 4. Februar 2020 18:29:20 MEZ schrieb Renato Barresi : >Hi Sylvain, > >I changed VJ_SUPPORT to 0 and still got the same behavior. > >I'm sending the PPP

[lwip-users] R: Re: lwip-users Digest, Vol 198, Issue 3

Hi Sylvain, I changed VJ_SUPPORT to 0 and still got the same behavior. I'm sending the PPP debug trace. Thank you for your help! Regards, Renato Updated lwipopts.h #define NETIF_DEBUG LWIP_DBG_ON #define HTTPD_DEBUG LWIP_DBG_ON #define TCP_DEBUG LWIP_DBG_ON

Re: [lwip-users] httpd POST gets stuck after few requests

Added "if (p != NULL) pbuf_free(p);" to the httpd_post_receive_data() and works like a charm. Thank you all. út 4. 2. 2020 v 17:49 odesílatel goldsimon napsal: > > > Trampas Stern wrote: > >err_t httpd_post_receive_data(void *connection, struct pbuf *p) > >{ > > pbuf_free(p); > >return ERR_OK;

Re: [lwip-users] httpd POST gets stuck after few requests

I found some info in httpd.c that has call to httpd_post_receive_data() /** Pass received POST body data to the application and correctly handle * returning a response document or closing the connection. * ATTENTION: The application is responsible for the pbuf now, so don't free it! * *

Re: [lwip-users] httpd POST gets stuck after few requests

Trampas Stern wrote: >err_t httpd_post_receive_data(void *connection, struct pbuf *p) >{ > pbuf_free(p); >return ERR_OK; >} Ah, yes. And the problem still is that the example does not do that. I'll file a bug... Regards, Simon ___ lwip-users

Re: [lwip-users] httpd POST gets stuck after few requests

I followed the contrib-2.1.0/examples/httpd/post_example/post_example.c, I did not notice any free of pbuf there. I guess if application is responsible for pbuf free then only httpd_post_receive_data() is candidate as it has pointer to data pbuf as parameter? út 4. 2. 2020 v 17:36 odesílatel

Re: [lwip-users] httpd POST gets stuck after few requests

err_t httpd_post_receive_data(void *connection, struct pbuf *p) { pbuf_free(p); return ERR_OK; } On Tue, Feb 4, 2020 at 11:35 AM goldsimon wrote: > > > Adam Baron wrote: > >I did search of POST related problems sorted by date. I will do so > >again. > > > >PBUF_POOL_SIZE is affecting number

Re: [lwip-users] httpd POST gets stuck after few requests

Adam Baron wrote: >I did search of POST related problems sorted by date. I will do so >again. > >PBUF_POOL_SIZE is affecting number of POST I can do directly. That is, >I >can do as many posts as PBUF_POOL_SIZE is defined. I think the user reporting this last time,did not free the pbuf passed

Re: [lwip-users] httpd POST gets stuck after few requests

I did search of POST related problems sorted by date. I will do so again. PBUF_POOL_SIZE is affecting number of POST I can do directly. That is, I can do as many posts as PBUF_POOL_SIZE is defined. @Trampas Stern I

Re: [lwip-users] httpd POST gets stuck after few requests

Adam Baron wrote: >OK, so my lwip gets stuck exactly after 16 POSTs. > >Maybe the POST is not freeing PCB, or other structures properly. I rather think not freeing a pbuf could be the cause. I think we had that a little while ago. Have you searched the list archive? Regards, Simon

Re: [lwip-users] httpd POST gets stuck after few requests

/** * MEMP_NUM_TCP_PCB: the number of simulatenously active TCP connections. * (requires the LWIP_TCP option) */ #define MEMP_NUM_TCP_PCB10 /** * MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections. * (requires the LWIP_TCP option) */ #define

Re: [lwip-users] Post messages with the httpd.c example

Hello, small MTU can be overridden by TCP_MSS I believe. The default 536 is very small for POST indeed. Adam út 4. 2. 2020 v 13:41 odesílatel Trampas Stern napsal: > The post parsing in the http code has couple problems. Most of the time > it will not cause issues. > > First it assume the

Re: [lwip-users] httpd POST gets stuck after few requests

Not sure which parameter is defining maximum number of connections. Processor is ARM 32bit STM32F407. út 4. 2. 2020 v 15:38 odesílatel Trampas Stern napsal: > What is the maximum number of connections you have setup? > > Which processor are you using? > > Trampas > > On Tue, Feb 4, 2020 at 9:08

Re: [lwip-users] httpd POST gets stuck after few requests

What is the maximum number of connections you have setup? Which processor are you using? Trampas On Tue, Feb 4, 2020 at 9:08 AM Adam Baron wrote: > I'm bit new to lwip, and I'm using it on STM32407 with ChibiOS which is > RTOS. I'm using current stable version of lwip and bindings form

[lwip-users] httpd POST gets stuck after few requests

I'm bit new to lwip, and I'm using it on STM32407 with ChibiOS which is RTOS. I'm using current stable version of lwip and bindings form ChibiOS to run it as threads. My static and also dynamically generated html pages are served well and without any issues. But I have problem with POST. I use the

Re: [lwip-users] Post messages with the httpd.c example

The post parsing in the http code has couple problems. Most of the time it will not cause issues. First it assume the first packet includes the entire POST header. With small MTU size this might not happen. Second it adds a null terminator at the end of the POST header before calling

Re: [lwip-users] DNS thread-safe functions

Simon, Noted! :) That’s why I said “I am not sure” ;) Regards, Ajay Bhargav From: Simon Goldschmidt Sent: Tuesday, February 4, 2020 5:10 PM To: lwip-users@nongnu.org Subject: Re: [lwip-users] DNS thread-safe functions Ajay Bhargav wrote: > [..] > However, I am not sure if dns_setserver really

Re: [lwip-users] DNS thread-safe functions

matteo.c...@alice.it wrote: > - LOCK_TCPIP_CORE / UNLOCK_TCPIP_CORE. They allow to access in exclusive way > to TCIPIP mechanism. However, I don’t want interfere with the regular > mechanisms of TCIPIP thread and of operating system; You don't. Unless you explicitly set LWIP_TCPIP_CORE_LOCKING to

Re: [lwip-users] DNS thread-safe functions

Ajay Bhargav wrote: > [..] > However, I am not sure if dns_setserver really needs to be protected so much > as there is nothing much going on except copying of server in an array. Please *don't* suggest things like this. You *need* protection: a) there is no guarantee the code will stay like it

Re: [lwip-users] POST gets stuck after few requests.

vysocan wrote: > Re-posting the debug since raw text was removed... If you want more people to read this, please: don't write from nabble. Instead, send a good old text-only email to the list. And ensure it's a readable length. I'm not even sure what your problem is... Thanks, Simon

Re: [lwip-users] POST gets stuck after few requests.

Re-posting the debug since raw text was removed... I have turn on the debugging messages and receiving following for good POST: /etharp_timer ethernet_input: dest:C2:AF:51:3:CF:46, src:AC:22:B:4F:46:93, type:800 ethernet_output: sending packet p ethernet_input: dest:C2:AF:51:3:CF:46,

Re: [lwip-users] DNS thread-safe functions

Hi, tcpip_api_call function will take care of everything. Its basically a wrapper function and works exactly the way Simon suggested if LWIP_TCPIP_CORE_LOCKING is enabled otherwise it will execute the function call from tcpip thread context and wait for it to finish. You can go ahead with this

[lwip-users] POST gets stuck after few requests.

I'm bit new to lwip, and I'm using it on STM32407 with ChibiOS which is RTOS. I'm using current stable version of lwip and bindings form ChibiOS to run it as threads. My static and also dynamically generated html pages are served well and without any issues. But I have problem with POST. I use the

Re: [lwip-users] Post messages with the httpd.c example

My observation is that httpd_post_receive_data is called for each received packet until content_len for this connection is reached. Then the httpd_post_finished is called for application to finalize. -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

[lwip-users] R: Re: DNS thread-safe functions

Dear Simon and Ajay, Thanks you so much for your attention in this matter. I appreciate your suggestions and I evaluate them carefully. I hope to interpret correctly the three your solutions: - LOCK_TCPIP_CORE / UNLOCK_TCPIP_CORE. They allow to access in exclusive way to TCIPIP mechanism.