[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: |
Carl D. Blake |
Subject: |
Re: [lwip-users] extra data at end of packet |
Date: |
Thu, 21 Dec 2006 16:02:59 -0700 |
Thank you. I eventually figured this out from my own investigation.
Thank you for the explanation.
For the second issue, I discovered that the way to handle the output
routines has changed. The example code in contrib showed the following
code:
err_t err;
err = etharp_output( nip, ipp, p );
if( err == ERR_OK ) {
/* send the frame */
netif_low_level_output( nip, p );
}
return err;
However, the newer code in CVS shows this:
return etharp_output( nip, ipp, p );
Apparently the operation of etharp_output was changed at some point to
output the packet itself rather relying on later code in the output
routine. When I used the newer code I stopped duplicating packets.
Things are looking much better now.
On Thu, 2006-12-21 at 14:32, David Empson wrote:
> 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.
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>