[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Empson
Subject: Re: [lwip-users] extra data at end of packet
Date: Fri, 22 Dec 2006 10:32:39 +1300

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]