extra data at end of packet

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

extra data at end of packet

Carl D. Blake
I've been looking closely at the data coming from lwip using tcpdump and
I have a couple of questions:

        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.

        2) In looking at the transmission of tcp packets between a server and
lwip I see an awful lot of retransmissions done by lwip.  I see repeated
packets several times.  Is there a setting for how often or how soon
lwip performs a retransmission of a packet?




_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: extra data at end of packet

David Empson
Carl D. Blake <[hidden email]> 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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: extra data at end of packet

Carl D. Blake
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 <[hidden email]> 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
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users