Just to make sure I'm doing this correctly....when an ethernet frame arrives, an interrupt is generated which calls low_level_input(). This is currently the only path into lwIP.
low_level_input() allocates a pbuf with p=pbuf_alloc(PBUF_RAW, len, PBUF_POOL), where len is set to what the hardware says the frame length is. I then memcpy the frame into p->payload, set p->len = len and p->tot_len = len since PBUF_POOL_BUFSIZE is set large enough to hold a full frame. I call ethernet_input(p, netif) and make sure it returns ERR_OK. Other than taking care of ethernet MAC housekeeping, that's all that's done with lwIP as far as frame Rx is concerned.
Am I doing anything wrong? In comparing another implementation that works perfectly using the same stack and httpd on another micro, the only difference is the ethernetif driver where this one is MIPS and uses descriptors/DMA and the functioning one is ARM and uses only CPU registers for ethernet Rx and Tx.
On Sunday, March 4, 2018, 3:26:31 PM CST, address@hidden <address@hidden> wrote:
On 03.03.2018 23:30, JM wrote:
So now the only entry into lwIP is through low_level_input().
I've spent a good deal of time trying to debug this and
where I got stuck was in tcp_receive() where it calls pbuf_clen(),
which returns MEMP_NUM_PBUF and that's where the
underflow originates. If I look at the pbuf passed into pbuf_clen() it does indeed have all pbufs
in existence chained to it. I can't understand where
this occurred however.
I guess this is because the pbuf you see is actually freed. The
'next' pointer of a pbuf just happens to be the same place as in the
list of free element in a mem pool.
To me it seems like a "use after free" bug.
Simon