Ethernet padding... - TCP-IP

This is a discussion on Ethernet padding... - TCP-IP ; When using Wireshark (Ethereal) I have noticed that 54-byte Ethernet frames get a 6-byte padding at the end (to make it a total of 60 bytes). However, the Ethernet header does not indicate what the total length of the frame ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Ethernet padding...

  1. Ethernet padding...


    When using Wireshark (Ethereal) I have noticed that 54-byte Ethernet frames
    get a 6-byte padding at the end (to make it a total of 60 bytes). However,
    the Ethernet header does not indicate what the total length of the frame is.
    The question is: how can I tell, by analyzing the data in the Ethernet
    frame, what the size of this padding is? Or, to phrase it differently: how
    can Wireshark tell?




  2. Re: Ethernet padding...

    "barcaroller" wrote:
    > When using Wireshark (Ethereal) I have noticed that 54-byte Ethernet
    > frames get a 6-byte padding at the end (to make it a total of 60
    > bytes). However, the Ethernet header does not indicate what the total
    > length of the frame is. The question is: how can I tell, by analyzing
    > the data in the Ethernet frame, what the size of this padding is? Or,
    > to phrase it differently: how can Wireshark tell?


    The determination of padding is determined by the next protocol in the
    frame. For example, one has to look at the "Total length" field in an IPv4
    datagram header to determine how much of the Ethernet frame contains valid
    data and disregard everything after that point as padding.

  3. Re: Ethernet padding...

    In article ,
    Jim Logajan wrote:

    >The determination of padding is determined by the next protocol in the
    >frame. For example, one has to look at the "Total length" field in an IPv4
    >datagram header to determine how much of the Ethernet frame contains valid
    >data and disregard everything after that point as padding.


    The other half of that is that the Ethernet protocol itself provides
    the length of the frame, so network interface drivers listen to what
    the MAC chip says. Upper layers such as IP check that the length of
    the frame reported by the driver from the Ethernet hardware is consistent
    with what the upper layer protocol expects from such as its header.


    Vernon Schryver vjs@rhyolite.com

  4. Re: Ethernet padding...

    vjs@calcite.rhyolite.com (Vernon Schryver) wrote:
    > In article ,
    > Jim Logajan wrote:
    >
    >>The determination of padding is determined by the next protocol in the
    >>frame. For example, one has to look at the "Total length" field in an
    >>IPv4 datagram header to determine how much of the Ethernet frame
    >>contains valid data and disregard everything after that point as
    >>padding.

    >
    > The other half of that is that the Ethernet protocol itself provides
    > the length of the frame, so network interface drivers listen to what
    > the MAC chip says. Upper layers such as IP check that the length of
    > the frame reported by the driver from the Ethernet hardware is
    > consistent with what the upper layer protocol expects from such as its
    > header.


    As far as consistency checking, all I know is that in practice for the
    TCP/IP stacks I have tested for this behavior, so long as the IPv4 Total
    Length field does not make it appear as if the datagram extends past the
    end of the Ethernet frame, any octets in the frame past the end of the
    datagram are ignored by the IP layer. (If the datagram claims to be longer
    than the actual number of octets delivered then it must be discarded before
    the checksum validation test.)

    In particular one test is to send short IP datagrams (~64 byte length
    datagrams) with full sized (1500 bytes data) frames where the frame is
    padded out with zero bytes. Using Maxwell from Interworking Labs we've
    tested that the stacks for Linux and Microsoft Windows XP do the right
    thing. If an interface is capable of handling jumbo frames the test is to
    set the interface MTU up and then send frames to the interface that are
    padded out to as large a frame as possible.

  5. Re: Ethernet padding...

    On Wed, 30 May 2007, in the Usenet newsgroup comp.protocols.tcp-ip, in article
    , Vernon Schryver wrote:

    >Jim Logajan wrote:
    >
    >>The determination of padding is determined by the next protocol in the
    >>frame. For example, one has to look at the "Total length" field in an IPv4
    >>datagram header to determine how much of the Ethernet frame contains valid
    >>data and disregard everything after that point as padding.

    >
    >The other half of that is that the Ethernet protocol itself provides
    >the length of the frame,


    Are you one of those committee radicals who run RFC1042 frames instead of
    the DIX/RFC0894 frames as Ghod and Bob Metcalfe intended? ;-)

    Old guy

  6. Re: Ethernet padding...

    ibuprofin@painkiller.example.tld (Moe Trin) writes:

    >>The other half of that is that the Ethernet protocol itself provides
    >>the length of the frame,

    >
    > Are you one of those committee radicals who run RFC1042 frames instead of
    > the DIX/RFC0894 frames as Ghod and Bob Metcalfe intended? ;-)


    I'm sure he meant the physical layer tells the receiver where the
    frame begins and ends, hence "providing the length". He wouldn't have
    been thinking of the 802.3 length field. (Quick, Kid: out the back
    door. I'll buy him another drink and that will settle him down. Just
    don't bring up 802.3 next time, ok?)

+ Reply to Thread