Re: [lwip-users] ip forward and pbuf corruption

[Tyrel Newton]

On Feb 6, 2012, at 11:22 AM, Kieran Mansley wrote:

> 
> On 5 Feb 2012, at 21:40, Tyrel Newton wrote:
> 
>> Does anybody have any clues as to where to look for the problem? My guess is 
>> that its somewhere in the etharp code, but I can't find it. Copying the 
>> entire pbuf is not exactly a good solution, though it definitely works.
> 
> The fact the copying solves the problem does suggest you have an issue with 
> the pbuf being freed, reused or corrupted.  Are you able to add any debug 
> tracing to your stack?  If so, I would add some logging to obvious places 
> like pbuf_free() and see if you can see the pbuf you are using being 
> released.  

I'm trying to avoid pbuf debugging because my ethernet driver uses pbuf_alloc 
from ISR context and the printf'ing would screw it up. I can make it work, but 
I was hoping to get some mailing list advice before I go that route.

My theory is that the pbuf len is being adjusted (via pbuf_header) by the 
etharp code after the frame is forwarded. The len change seems to indicate the 
etharp code because the change is a 2-byte multiple (not divisible by 4-bytes), 
which is indicative of the 14-byte etharp frame size. Of course, this could 
mean the pbuf is prematurely free'd and realloc'd as another etharp frame. Btw, 
the forwarded IP frames should all be alloc'd from the pbuf_pool storage as 
this is what my netif drivers use. Hopefully I can look into this further today.

> 
> The way that you are using the pbufs is a little unusual.  Which API are you 
> using to lwIP?  Or are you modifying lwIP internally to get the forwarding 
> behaviour?

Why is this unusual pbuf usage? I am using the tcpip thread (netconn api), so 
the re-transmission of the IP frames should be happening from the context of 
the tcpip thread. The IP forwarding is provided inherently by the ipv4 code (in 
the ip_forward function).

Tyrel