From your description, it seems like memory beloging to a packet is being changed after being delivered to your netif->linkoutput function. Does your MAC support DMA? If so, make sure the pbufs are freed after receiving a transmit interrupt for the packet. (pbuf_free(p) then must *not* be called directly in the linkoutput function! Doing so leads to memory being freed before it is actually transmitted. Thus the next call to pbuf_alloc will get the same pbuf and may alter the data while the MAC sends it using its DMA engine.
Simon
JM wrote:
> I'm using lwIP on a Stellaris micro, and saw lots of dropped packets. Upon further investigation, it turns out these packets were failing TCP checksum. I noticed that if I enabled debugging in the
correct areas, and enough of it, the issue went away. Long story short, after lots of trial and error I discovered that if I disable debugging and add a delay of 300us at the very end, before the return, in ip_output_if(), it fixes the problem. If I decrease the delay, the problem starts appearing and becomes worse as I continue to decrease the delay.
> The driver for the onboard ethernet controller is from the Luminary driver library. I don't imagine that a very high percentage of users here use the same chip I'm using, but generally speaking, any idea what I can look for; what would cause this? I'm mainly recieving data. It's streaming audio data so once I initiate it, the stack only has to ACK.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> lwip-users mailing list
>
address@hidden>
http://lists.nongnu.org/mailman/listinfo/lwip-users_______________________________________________
lwip-users mailing list
address@hiddenhttp://lists.nongnu.org/mailman/listinfo/lwip-users