[lwip-users] Using pbufs in a recv function - next vs ref vs tot_len

[Chris Frost]

I've been tracking down a bug in a program using lwip's rawapi, but my
solution seems odd so I was hoping to ask a quick question about the use
of pbuf's in one's recv function (that is passed to tcp_recv).

Originally, I did something like this:
recv(void *arg, struct tcp *pcb, struct pbuf *p, err_t err)
{
        for(; p; p = p->next)
        ...
}

However, this seemed to be incorrect because of many asserts lwip made, eg
pbuf_free: p->ref > 0. From the code in lwip that I found, all pbuf code
appeared to do this, but perhaps I've misread code, or the pbuf structure
is used differently in different places? My first change was to add to the for
condition p->ref > 0. I then found I would receive much more data than
was going across the network. (In particular, large regions of zeros.)
In addition to next and ref there is the tot_len field. Changing the for
loop condition to (p && bytes_recved < total_bytes_from_orig_p_tot_len)
appears to work perfectly. So this is good. :)

My question is, is this use of pbufs in the recv function correct? While
it functional appears to be, it seems odd to me (not being too familiar
with lwip's internal workings) that length, ref, and next do not agree on
when the data in a list of pbufs ends. The lwip code I have looked at that
uses pbufs (and our ethernet driver) just checks what seems most obvious,
next. I've not read any applications that use pbuf lists, the only one
I have seen is the http client in contrib, but this only inspects the
first pbuf.

thanks for any help clearing up/confirming the use of the pbuf interface!
-- 
Chris Frost  |  <http://www.frostnet.net/chris/>
-------------+----------------------------------
Public PGP Key:
   Email address@hidden with the subject "retrieve pgp key"
   or visit <http://www.frostnet.net/chris/about/pgp_key.phtml>