Re: extra data at end of packet

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 <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.
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>