This wiki has been migrated to and is now deprecated. Please use that site instead.
Differences between revisions 24 and 25
Revision 24 as of 2005-09-04 22:38:25
Size: 10807
Editor: UlfLamping
Revision 25 as of 2005-11-13 11:45:16
Size: 10804
Editor: GuyHarris
Comment: You can't indent headers.
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
 === MAC address fields === === MAC address fields ===
Line 37: Line 37:
 === Type / Length field === === Type / Length field ===
Line 62: Line 62:
 === Frame Check Sequence (FCS) field === === Frame Check Sequence (FCS) field ===

Ethernet (IEEE 802.3)



Ethernet is the most common local area networking technology, and, with gigabit and 10 gigabit Ethernet, is also being used for metropolitan-area and wide-area networking.

It is specified by [ various IEEE 802.3 specifications].

Ethernet sends network packets from the sending host to one (["Unicast"]) or more (["Multicast"]/["Broadcast"]) receiving hosts.

You can find hardware related Ethernet information at the EthernetHardware page.

Information how to capture on an Ethernet network can be found at the ["CaptureSetup/Ethernet"] page.

Packet format

A physical Ethernet packet will look like this:


Destination MAC address

Source MAC address


User Data

Frame Check Sequence (FCS)





46 - 1500


As the Ethernet hardware filters the preamble, only the green fields are given to Ethereal or any other application. Most Ethernet interfaces also either don't supply the FCS to Ethereal or other applications, or aren't configured by their driver to do so.

MAC address fields

Type / Length field

  • The original DEC/Intel/Xerox Ethernet specification included a 16-bit type field to indicate what upper layer protocol should be used. Ethernet frames with less than 64 bytes of Ethernet header, user data, and FCS are padded to 64 bytes (which means 60 bytes of Ethernet header and user data), which means that if there's less than 64-(14+4) = 46 bytes of user data in the frame, extra user data is added to the frame. If the upper layer protocol implementation has to know exactly how much user data is in the packet, and expects the length of the Ethernet packet to indicate the amount of user data, it will not behave correctly with padded packets.

    When constructing standards for LANs, the IEEE added a new header, the [ 802.2] LLC header, to packets in those LANs. It contained a destination "service access point", source "service access point", and packet type field, similar to the packet type field used in HDLC and HDLC-derived protocols such as X.25's LAPB; the destination service access point indicated the service to which the packet should be delivered, where a "service" is implemented as a protocol. (XXX - is the notion of service and protocol formalized in the OSI reference model? If so, we should perhaps have a page for the OSI model and describe that notion, and link to it.) I.e., it indicates the upper layer protocol that should be used. This meant that the type field in Ethernet could be used for other purposes, if an 802.2 header appeared at the beginning of the user data, so the IEEE standard for Ethernet, IEEE 802.3, included after the source MAC address a 16-bit field indicating the length of the user data in the packet, for the benefit of protocols that couldn't infer the length of the user data from the length of the packet as received.

    However, that standard also had to support the traditional use of that field as a type field. Ethernet packets could have no more than 1500 bytes of user data, so the field is interpreted as a length field if it has a value <= 1500 and a type field if it has a value > 1500. (XXX - the maximum length value is slightly smaller than the minimum type value.) Therefore, if the type/length field has a value 1500 or lower, it's a length field, and is followed by an 802.2 header, otherwise it's a type field and is followed by the data for the upper layer protocol.

    For a more detailed discussion of this, which mentions a third possibility used by NetWare, and mentions the SNAP header that can follow the 802.2 header, see [ Ethernet Frame Types: Provan's Definitive Answer], by Don Provan. Some examples of values in the type/length field:

    • 0 - 45 invalid
    • 46 - 1500 length field (802.3 + 802.2)
    • 0x0800 IP(v4), Internet Protocol version 4
    • 0x0806 ARP, Address Resolution Protocol
    • 0x8137 IPX, Internet Packet eXchange (Novell)
    • 0x86dd IPv6, Internet Protocol version 6

    See [ Ethernet numbers] at the ["IANA"], [ Michael A. Patton's list of Ethernet type codes], and [ the IEEE's list of public Ethernet type assignments] for lists of some assigned Ethernet type codes. You can also search for a particular Ethernet type from [ the IEEE EtherType Registration Authority page]; enter the Ethernet type in hex, without a leading 0x. (Not all assigned Ethernet type codes are reported publicly.)

Frame Check Sequence (FCS) field

  • Ethernet uses a CyclicRedundancyCheck (CRC) algorithm to detect transmission errors. The FrameCheckSequence field is filled (using a CRC) by the sending host. If the receiving host detects a wrong CRC, it will throw away that packet.


See [ Wikipedia] for a brief history of Ethernet

Protocol dependencies

Ethernet is the lowest software layer, so it only depends on hardware.

Example traffic

Small portion of the capture from opening in a web browser.

  • No.     Time        Source                Destination           Protocol Info
          1 0.000000       TCP      1061 > http [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
          2 0.063590           TCP      http > 1061 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1380
          3 0.063665       TCP      1061 > http [ACK] Seq=1 Ack=1 Win=16560 Len=0
          4 0.064056       HTTP     GET / HTTP/1.1
          5 0.163470           TCP      http > 1061 [ACK] Seq=1 Ack=399 Win=6432 Len=0
          6 0.193849           HTTP     HTTP/1.1 200 OK (text/html)
          7 0.201317           HTTP     Continuation
          8 0.201408       TCP      1061 > http [ACK] Seq=399 Ack=2761 Win=16560 Len=0
          9 0.208895       TCP      1062 > http [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
         10 0.280617           HTTP     Continuation
         11 0.287876           HTTP     Continuation

Example capture file

Full capture from above example. Opening from the Firefox browser.

  • attachment:SampleCaptures/


The Ethernet dissector is fully functional.

Preference Settings

(XXX add links to preference settings affecting how Ethernet is dissected).

Display Filter

A complete list of Ethernet display filter fields can be found in the [ display filter reference]

Some useful filters:

  • Filter

    Traffic Description


    all Ethernet based 

    to and from Ethernet MAC address 08:00:08:15:ca:fe


    all except to and from Ethernet MAC address 08:00:08:15:ca:fe


    Ethernet ["Broadcast"] only


    all except Ethernet ["Broadcast"]

    (eth.dst[0] & 1) 

    Ethernet ["Multicast"] only (least significant bit of first address byte set)

    !(eth.dst[0] & 1) 

    all except Ethernet ["Multicast"] (least significant bit of first address byte not set)

Note: the Ethernet Broadcast address (ff:ff:ff:ff:ff:ff) is per definition a Multicast one (least significant bit of first address byte set). If you want to see only Multicasts, you have to filter out the Broadcasts as well  (eth.dst[0] & 1) && eth.dst!=ff:ff:ff:ff:ff:ff .

Capture Filter

Capture only the Ethernet-based traffic to and from Ethernet MAC address 08:00:08:15:ca:fe:

  •  ether host 08:00:08:15:ca:fe 

Ethernet ["Multicast"] traffic only:

  •  ether multicast 

Ethernet ["Broadcast"] traffic only:

  •  ether broadcast 

Information how to capture on an Ethernet network can be found at the ["CaptureSetup/Ethernet"] page.

A lot of tutorial information about Ethernet can be found at [ Charles Spurgeon's Ethernet Web Site].


Ethernet (last edited 2020-06-29 17:39:11 by ChuckCraft)