[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Pbuf chain

From: Simon Goldschmidt
Subject: Re: [lwip-users] Pbuf chain
Date: Fri, 30 May 2014 12:40:15 +0200

Mike He wrote:

> If my understanding is correct, the pbuf that is passed to our recv callback 
> is only the first in a chain, where we must traverse the chain to obtain the 
> full packet?
> [..]
> Why would there be two conditions? Is ever one true when the other isn't? How 
> do the lengths add up if the first condition is true but the second isn't?

It's a little bit confusing, but not too much. A packet is a queue of pbufs, 
the packet length is tot_len of the first pbuf. That means when there is only a 
single packet in the queue, the last pbuf has tot_len==len and next==NULL.

In the application callbacks, this is pretty much it. However, inside the 
stack, there is code that has to buffer multiple packets (which are separated 
again before being passed to the application callbacks). It uses the 'next' 
pointer of the last pbuf and points it to the first pbuf of the next packet. If 
you would iterate such a pbuf list until next==NULL, you would get more bytes 
than the first pbuf's tot_len. This could potentially lead to a buffer 
overflow, which is why your application should check for the length, too, in 
addition to a NULL pointer.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]