[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE
From: |
address@hidden |
Subject: |
Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE |
Date: |
Fri, 09 Dec 2011 15:44:46 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
Gary Spivey wrote:
Which apparently is packing 2 bytes worth of 0 into the ethernet header.
So ... the ethernet header is padding the packet with ETH_PAD_SIZE bytes of 0.
That's what ETH_PAD_SIZE is meant to do, yes. Obviously, you must not
send out these 2 padding bytes on the wire...
So - is this the advised way to handle this?
No.
(It works :-)
It might, for now, but it's not correct, and so might produce errors later.
There is a perfectly good example in our 'ethernetif.c' of how to handle
pbuf chains in the send and receive path. Please follow them instead of
creating your own code and wondering why it doesn't work.
In short, only the first pbuf of a chain has padding, the others don't.
Simon
- [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Gary Spivey, 2011/12/07
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, web, 2011/12/07
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Gary Spivey, 2011/12/07
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Bill Auerbach, 2011/12/08
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Gary Spivey, 2011/12/08
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Kieran Mansley, 2011/12/08
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Gary Spivey, 2011/12/08
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Gary Spivey, 2011/12/08
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE,
address@hidden <=
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Simon Goldschmidt, 2011/12/09
- Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE, Simon Goldschmidt, 2011/12/09