Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE

[web]

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