I have to admit it. I am now lost. Am I supposed to call pbuf_alloc with a number larger than PBUF_POOL_BUFSIZE?
I implemented this by calling pbuf_alloc with a size larger than a PBUF_POOL_BUFSIZE can hold. It allocated multiple pbufs and chained them together. However when I do this, DHCP no longer works. So, I bumped the TCP_MSS up to 636 rather than the default 536 (and bigger than the 594 I was receiving). This made it past DHCP, but didn’t echo packets (using the tcpecho contrib program). As a side note, this is all with PBUF_LINK_HLEN set to 16. If I don’t set it (and let it default to 14 + ETH_PAD_SIZE) and then set ETH_PAD_SIZE to 2, I am back to things not working (like DHCP). What is the preferred way to configure lwip so that I can either accept packets larger than PBUF_POOL_BUFSIZE or ensure that I don’t receive them? I would be more than willing to read whatever resources … and I have been scouring docs and the web … but any help would be greatly appreciated. -Gary From: [email protected] [mailto:[email protected]] On Behalf Of Bill Auerbach Sent: Thursday, December 08, 2011 5:20 AM To: 'Mailing list for lwIP users' Subject: Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE A pbuf of PBUF_POOL_BUFSIZE is alloctated for every pbuf_alloc of PBUF_POOL. So PBUF_POOL_BUFSIZE must be the same or larger than any incoming our outgoing packet that’s going to use a pbuf_alloc to obtain a packet buffer. I had a similar problem to yours in not adding ETH_PAD_SIZE (2) to PBUF_POOL_BUFSIZE and every pbuf_alloc for a packet had a chained pbuf with the second pbuf containing the 2 bytes. PBUF_POOL_BUFSIZE doesn’t constrain the incoming our outgoing packet size – it’s the maximum size that’s going to be used for all PBUF_POOL pbuf_allocs. Bill From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Gary Spivey Sent: Wednesday, December 07, 2011 5:47 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE Thanks, this doesn’t yet work for me … but it does change the problem and leads me to another question that might help. It appears that the buffer allocate does not give me a buffer of the size requested, but constructs a chain of buffers whose total size is what has been requested. What I have been doing is getting the buffer address and copying the entire received Ethernet buffer into that address. With this change, it seems clear that I cannot do this, but that I have to manage the copy into this chain of buffers. Is there an lwip-provided method to do this, or do I just need to follow the chain myself? I am looking through the documentation, but I haven’t found anything yet. -Gary
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
