Carl D. Blake <carl-OfnAgNkcTZ154TAoqtyWWQ@xxxxxxxxxxxxxxxx> 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.
