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

[Tyrel Newton]

On 2/5/2012 1:40 PM, Tyrel Newton wrote:
> I have a system with two netifs and I'm trying to forward packets 
> between the two interfaces. One netif is my Ethernet interface while 
> the other is a custom wireless interface. The problem is that the 
> forwarded pbuf is getting corrupted somehow before I can send it back 
> out. At first I thought the forwarded pbuf was getting free'd 
> prematurely, but an additional pbuf_ref does not fix the problem. I 
> know the pbuf enters my second netif correctly, but before I can get 
> it sent out, its either being free'd or modified somehow again. At the 
> moment its working, but its because I'm copying the forwarded pbuf 
> before sending it back out.
>
> I have gone over the code numerous times and traced the pbuf from the 
> rx of my ethernet interface, through the etharp code, through ip 
> forward, and into my second netif driver and I can't figure out where 
> the problem is. I'm currently running the latest code in the git repo 
> (as of yesterday).
>
> 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.
In case anybody else runs into a similar problem, the reason for the 
corruption was in my own netif drivers and is related to the placement 
of the pbuf->payload within the contiguous memory of the pbuf/payload 
combo and differing link layer header sizes between my Ethernet netif 
driver and my other "custom" netif driver.

The part that caught me up for so long is that the placement of the 
payload in Rx and Tx packets is inherently different. That is, its 
common to pack the Rx packet at the very beginning of the payload memory 
region while Tx packets are offset by an amount that is easily adjusted 
by the PBUF_LINK_HLEN configuration parameter.

The best solution I can think of to this problem is to pack my Rx 
Ethernet packets at a payload offset of "PBUF_LINK_HLEN - 
SIZEOF_ETH_HDR". This would still allow me to set the "maximum link 
layer header size" by simply adjusting the PBUF_LINK_HLEN parameter, 
which is what I've been doing to date.

Has anybody else ran into a similar problem or have further insight into 
different solutions?

Tyrel