Re: [lwip-users] extra data at end of packet

[David Empson]

Carl D. Blake <address@hidden> wrote:
> 1) On some tcp packets - usually 1 byte or 0 byte packets there is
> extra data at the end.  The IP header indicates the correct length, but
> there will be 5 bytes of extra data if the tcp packet size is 1 byte or
> 6 bytes of extra data if the tcp packet size is 0 (e.g. for an ACK).
> This extra data seems to consist of the window, checksum, and urgent
> pointer field data - those fields are repeated.  It's as if lwip has to
> send at least 6 bytes of data in every tcp packet.  An example is a 1
> byte tcp packet: the IP header shows a total length of 41 bytes, the
> internet header length is 5 32bit words, the tcp header length is 5 32
> bit words, and there is 1 byte of data - however the packet itself has 5
> bytes of extra data that consist of the window field, then the checksum
> field, and then the first byte of the urgent pointer field.

This is presumably on Ethernet? Ethernet has a minimum packet length of 64 
bytes. After excluding the Ethernet header, the minimum payload length is 46 
bytes. Exclude the IP and TCP headers (20 bytes each) and there is a minimum 
data length of 6 bytes.

When transmitting a packet shorter than this, the packet must be padded out 
to the minimum length. This is often done by the Ethernet MAC. It may just 
generate arbitrary data or repeat part of the packet (which is more secure 
than sending something which happens to be located in the next few bytes of 
memory).

After it arrives at the receiving MAC and is verified, the pad data is 
typically discarded, as long as the packet was sent using IEEE 802.3 format 
(with a length field). If it is a DEC/Intel/Xerox Ethernet packet with a 
type field (as it normally is for TCP/IP), the correct length must be 
inferred from other data in the packet, and it is up to higher layers to 
discard the padding. The IP header has enough information to determine where 
the padding starts.