Re: [lwip-users] Assertion "pcb->snd_queuelen >= pbuf_clen(next->p)" failed after TCP handshake

[address@hidden]

Am 21.04.2021 um 10:38 schrieb Tomas Mudrunka:
> Hello,
> i have written my own netif driver on FreeRTOS+LWIP.
> Pings work reliably, TCP handshake works reliably,
> but once i start sending data to the established TCP connection it
> crashes on this:
>
> assertion "pcb->snd_queuelen >= pbuf_clen(next->p)" failed: file
> "/opt/Espressif/esp-idf/components/lwip/lwip/src/core/tcp_in.c", line
> 1112, function: tcp_free_acked_segments
>
> My netif has FreeRTOS task which handles communication and then passes
> received L2 frames to LWIP like this:
>
> p = pbuf_alloc(PBUF_RAW,rx_len,PBUF_POOL);
> pbuf_take(p, rx_buf, rx_len);
> if(netif->input(p, netif) != ERR_OK) {
>    ESP_LOGE(TAG, "Input failed!");
>    pbuf_free(p);
> }
>
> Netif task runs with same priority as LWIP task.
> (Both run at ESP_TASK_TCPIP_PRIO defined in esp_task.h, but that is
> ESP32 specific)
> When i was running task with higher priority it was causing deadlocks.
> Now when i run both task on the same priority it gives me assertion
> mentioned before...
>
> Any idea what might be causing this?
> I am not sure how should i handle the case with netif having its own
> task sending data to netif->input()
> Is there some explicit locking required?

This is a special case where locking is taken care of. However:
- SYS_LIGHTWEIGHT_PROT needs to be set (this takes care of locking the
memp pools)
- pbuf_alloc/pbuf_take/pbuf_free are ok to call from your own thread as
long as you don't use the heap (e.g. don't use PBUF_RAM, don't enable
MEMP_MEM_MALLOC)
- netif->input must point to tcpip_input() to ensure the actual packet
processing takes place in lwIP thread context, not in your RX thread. To
do that, pass tcpip_input (not ethernet_input) to netif_add().

Regards,
Simon

>
> Thanks for your help.
>