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
From: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden
On Behalf Of address@hidden
Sent: Wednesday, December 07, 2011 1:55 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE
On 7 dec 2011 20:28 "Gary Spivey"
<address@hidden> wrote:
I am using lwip-1.4.0 in RAW mode on a NXP LPC1788 (ARM Cortex-M3, 32-but arch). I have implemented the tcp_echo example and all works well when sending simple packets. However, when the packets get a little larger, things start to break
down. I have traced it to the following:
In my lowest level driver, I receive an Ethernet packet with a payload of 594 bytes. This gets copied into an lwip buffer that is allocated using:
p = pbuf_alloc(PBUF_RAW, PBUF_POOL_BUFSIZE, PBUF_POOL);
The defaults in my lwip\opt.h file are (in reverse order):
#define PBUF_POOL_BUFSIZE LWIP_MEM_ALIGN_SIZE(TCP_MSS+40+PBUF_LINK_HLEN)
#define PBUF_LINK_HLEN (14 + ETH_PAD_SIZE)
#define ETH_PAD_SIZE 0
#define TCP_MSS 536
And my lwipopts.h file has
#define MEM_ALIGNMENT 4
And so the PBUF_POOL_BUFSIZE is only LWIP_MEM_ALIGN_SIZE(590) which results in 592 – less than the 594 bytes coming in .
Why am I getting 594 bytes coming in and I only have 592 bytes allocated to hold it? How do I fix this? (Scaling the TCP_MSS scales the problem).
-Gary
You are getting 594, if that's what is sent on the network.
LWIP_MEM_ALIGN_SIZE(590) rounds the selected size 590 upwards to the closest number that matches the selected alignment requirement, which in this case means 592.
If you get a incoming frame of 594 Bytes, you shall call:
p = pbuf_alloc(PBUF_RAW, 594, PBUF_POOL);
(replace "594" with the variable holding the actual size)
Simple as that.
Regards,
Timmy Brolin