lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Correct way to free pbufs after tcp_recv callback finis


From: Gabriel Harrison
Subject: Re: [lwip-users] Correct way to free pbufs after tcp_recv callback finished
Date: Tue, 28 Jun 2016 09:23:30 +0000

Hi,

 

Thank you for the pointer to rawapi.txt. I think the following answers the question:

 

  …The callback function will be passed a NULL pbuf to

  indicate that the remote host has closed the connection. If

  there are no errors and the callback function is to return

  ERR_OK, then it must free the pbuf. Otherwise, it must not

  free the pbuf so that lwIP core code can store it.

 

Is a call to pbuf_free() the correct mechanism to do this or should it be via a tcp_ level function?

 

Regards,

 

Gabriel

 

 

Gabriel Harrison

Software Engineer

 

Tel:     +44(0) 1740 626099

Fax:    +44(0) 1740 626061

 

 

 

From: lwip-users [mailto:lwip-users-bounces+address@hidden On Behalf Of goldsimon
Sent: 27 June 2016 18:22
To: Mailing list for lwIP users <address@hidden>
Subject: Re: [lwip-users] Correct way to free pbufs after tcp_recv callback finished

 

Please read doc/rawapi.txt where this is documented.

Noam, I'm a bit confused. The PCB passed to the recv callback should be the one passed to tcp_recved. To handle the listen callback, this is different...

Simon

Gesendet mit AquaMail für Android
http://www.aqua-mail.com

Am 27. Juni 2016 5:31:01 nachm. schrieb Noam Weissman <address@hidden>:

Hi,

 

You need to call pbuf_free(pcb) after you finish processing the data.

 

Also you need to call tcp_recived after you handled the data. You call it NOT

with the pcb that you get inside the recv call back but rather your SERVER pcb.

The one created after calling listen.

 

I am not at my working PC so I cannot add an example but search around you

will see what I mean.

 

BR,

Noam.

 


From: lwip-users <lwip-users-bounces+address@hidden> on behalf of Gabriel Harrison <address@hidden>
Sent: Monday, June 27, 2016 1:41 PM
To: address@hidden
Subject: [lwip-users] Correct way to free pbufs after tcp_recv callback finished

 

Hi,

 

We’ve started our first lwIP project, following the instructions on http://lwip.wikia.com/wiki/Raw/TCP to create our high level functions and taking the device level IRQ functions and ethernetif.c from the SDK for our chip (Freescale Kinetis K60)

lwip.wikia.com

Initialization Edit. lwip_init() must be called before any tcp functions are called. void tcp_tmr(void) After lwip_init() is called, you must call tcp_tmr ...

 

Although we appear to have set things up correctly – we can send & receive requests – the TCP pbufs pool is not running out and it looks like they are not being freed after the receive has been processed.

 

I can see in tcp_recv_null in tcp.c that pbuf_free(p); is called after tcp_recved(pcb, p->tot_len); but I can’t find any info about freeing the pbufs in the wiki via either pbuf_free or pbuf_free_callback.

 

Should I be calling pbuf_free/ pbuf_free_callback in our receive callback or is this supposed to be handled elsewhere?

 

Thanks,

 

Gabriel


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

reply via email to

[Prev in Thread] Current Thread [Next in Thread]