On 7 dec 2011 20:28 "Gary Spivey" <[email protected]> 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 >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
