I thought I'd respond and explain what ended up being the problem. Simply put, I was calling pbuf_free(p); after transmitting the frame in low_level_output().
I used an lwIP implementation for another micro as a guide and it seemed this is what it did. But after an elaborate debugging setup revealed the pbuf in the active pcb always had all pbufs linked after transmitting a certain packet, I checked the lwIP supplied ethernetif.c example and, it wasn't called pbuf_free()! I commented it out and it works great.
I had a suspicion it was something small and stupid, but finding it is the problem.
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