Differences between revisions 40 and 41
Revision 40 as of 2008-01-03 09:17:03
Size: 13114
Editor: UlfLamping
Comment:
Revision 41 as of 2008-04-12 17:51:45
Size: 13154
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
[[TableOfContents(3)]] <<TableOfContents(3)>>
Line 8: Line 8:
It is specified by [http://standards.ieee.org/getieee802/802.3.html various IEEE 802.3 specifications]. It is specified by [[http://standards.ieee.org/getieee802/802.3.html|various IEEE 802.3 specifications]].
Line 10: Line 10:
Ethernet sends network packets from the sending host to one (["Unicast"]) or more (["Multicast"]/["Broadcast"]) receiving hosts. Ethernet sends network packets from the sending host to one ([[Unicast]]) or more ([[Multicast]]/[[Broadcast]]) receiving hosts.
Line 14: Line 14:
Information how to capture on an Ethernet network can be found at the ["CaptureSetup/Ethernet"] page. Information how to capture on an Ethernet network can be found at the [[CaptureSetup/Ethernet]] page.
Line 40: Line 40:
The first three bytes of the address are assigned to a specific vendor or organization; they're referred to as an Organizationally Unique Identifier, or an OUI. See [http://standards.ieee.org/regauth/oui/oui.txt the IEEE OUI list], [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] at the ["IANA"], [http://www.cavebear.com/CaveBear/Ethernet/vendor.html Michael A. Patton's list of vendor codes], and [http://anonsvn.wireshark.org/wireshark/trunk/manuf Wireshark's list of Ethernet vendor codes and well-known MAC addresses], from the Wireshark source distribution, for assigned OUIs. You can also search for a particular OUI from [http://standards.ieee.org/regauth/oui/index.shtml the IEEE OUI and Company_id Assignments page]. The first three bytes of the address are assigned to a specific vendor or organization; they're referred to as an Organizationally Unique Identifier, or an OUI. See [[http://standards.ieee.org/regauth/oui/oui.txt|the IEEE OUI list]], [[http://www.iana.org/assignments/ethernet-numbers|Ethernet numbers]] at the [[IANA]], [[http://www.cavebear.com/CaveBear/Ethernet/vendor.html|Michael A. Patton's list of vendor codes]], and [[http://anonsvn.wireshark.org/wireshark/trunk/manuf|Wireshark's list of Ethernet vendor codes and well-known MAC addresses]], from the Wireshark source distribution, for assigned OUIs. You can also search for a particular OUI from [[http://standards.ieee.org/regauth/oui/index.shtml|the IEEE OUI and Company_id Assignments page]].
Line 42: Line 42:
A destination MAC address of ff:ff:ff:ff:ff:ff indicates a ["Broadcast"], meaning the packet is sent from one host to any other on that network. A destination MAC address of ff:ff:ff:ff:ff:ff indicates a [[Broadcast]], meaning the packet is sent from one host to any other on that network.
Line 44: Line 44:
A destination MAC address where the low-order bit of the first byte is set indicates a ["Multicast"], meaning the packet is sent from one host to all hosts on the network interested in packets sent to that MAC address. A number of multicast addresses have been assigned; see [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] at the ["IANA"], [http://www.cavebear.com/CaveBear/Ethernet/multicast.html Michael A. Patton's list of multicast addresses], and [http://anonsvn.wireshark.org/wireshark/trunk/manuf Wireshark's list of Ethernet vendor codes and well-known MAC addresses], from the Wireshark source distribution, for assigned multicast addresses. A destination MAC address where the low-order bit of the first byte is set indicates a [[Multicast]], meaning the packet is sent from one host to all hosts on the network interested in packets sent to that MAC address. A number of multicast addresses have been assigned; see [[http://www.iana.org/assignments/ethernet-numbers|Ethernet numbers]] at the [[IANA]], [[http://www.cavebear.com/CaveBear/Ethernet/multicast.html|Michael A. Patton's list of multicast addresses]], and [[http://anonsvn.wireshark.org/wireshark/trunk/manuf|Wireshark's list of Ethernet vendor codes and well-known MAC addresses]], from the Wireshark source distribution, for assigned multicast addresses.
Line 51: Line 51:
When constructing standards for LANs, the IEEE added a new header, the [http://standards.ieee.org/getieee802/802.2.html 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. When constructing standards for LANs, the IEEE added a new header, the [[http://standards.ieee.org/getieee802/802.2.html|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.
Line 59: Line 59:
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 [http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html Ethernet Frame Types: Provan's Definitive Answer], by Don Provan. 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 [[http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html|Ethernet Frame Types: Provan's Definitive Answer]], by Don Provan.
Line 71: Line 71:
See [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] at the ["IANA"], [http://www.cavebear.com/CaveBear/Ethernet/type.html Michael A. Patton's list of Ethernet type codes], and [http://standards.ieee.org/regauth/ethertype/eth.txt 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 [http://standards.ieee.org/regauth/ethertype/index.shtml 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.) See [[http://www.iana.org/assignments/ethernet-numbers|Ethernet numbers]] at the [[IANA]], [[http://www.cavebear.com/CaveBear/Ethernet/type.html|Michael A. Patton's list of Ethernet type codes]], and [[http://standards.ieee.org/regauth/ethertype/eth.txt|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 [[http://standards.ieee.org/regauth/ethertype/index.shtml|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.)
Line 77: Line 77:
See [http://en.wikipedia.org/wiki/Ethernet#History Wikipedia] for a brief history of Ethernet See [[http://en.wikipedia.org/wiki/Ethernet#History|Wikipedia]] for a brief history of Ethernet
Line 101: Line 101:
 . attachment:SampleCaptures/wireshark.org.pcap.gz  . [[attachment:SampleCaptures/wireshark.org.pcap.gz]]
Line 109: Line 109:
A complete list of Ethernet display filter fields can be found in the [http://www.wireshark.org/docs/dfref/e/eth.html display filter reference] A complete list of Ethernet display filter fields can be found in the [[http://www.wireshark.org/docs/dfref/e/eth.html|display filter reference]]
Line 118: Line 118:
 ||{{{eth.dst==ff:ff:ff:ff:ff:ff }}} ||Ethernet ["Broadcast"] only ||
 ||{{{eth.dst!=ff:ff:ff:ff:ff:ff }}} ||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) ||
 ||{{{eth.dst==ff:ff:ff:ff:ff:ff }}} ||Ethernet [[Broadcast]] only ||
 ||{{{eth.dst!=ff:ff:ff:ff:ff:ff }}} ||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) ||
Line 129: Line 129:
Ethernet ["Multicast"] traffic only: Ethernet [[Multicast]] traffic only:
Line 133: Line 133:
Ethernet ["Broadcast"] traffic only: Ethernet [[Broadcast]] traffic only:
Line 141: Line 141:
Information how to capture on an Ethernet network can be found at the ["CaptureSetup/Ethernet"] page. Information how to capture on an Ethernet network can be found at the [[CaptureSetup/Ethernet]] page.
Line 144: Line 144:
A lot of tutorial information about Ethernet can be found at [http://www.ethermanage.com/ethernet/ethernet.html Charles Spurgeon's Ethernet Web Site]. A lot of tutorial information about Ethernet can be found at [[http://www.ethermanage.com/ethernet/ethernet.html|Charles Spurgeon's Ethernet Web Site]].

Ethernet (IEEE 802.3)

Overview

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:

Preamble

Destination MAC address

Source MAC address

Type/Length

User Data

Frame Check Sequence (FCS)

8

6

6

2

46 - 1500

4

As the Ethernet hardware filters the preamble, it is not given to Wireshark or any other application. Most Ethernet interfaces also either don't supply the FCS to Wireshark or other applications, or aren't configured by their driver to do so; therefore, Wireshark will typically only be given the green fields, although on some platforms, with some interfaces, the FCS will be supplied on incoming packets.

Allowed Packet Lengths

Ethernet packets with less than the minimum 64 bytes for an Ethernet packet (header + user data + FCS) are padded to 64 bytes, which means that if there's less than 64-(14+4) = 46 bytes of user data, extra padding data is added to the packet.

Beware: the minimum Ethernet packet size is commonly mentioned at 64 bytes, which is including the FCS. This can be confusing as the FCS is often not shown by Wireshark, simply because the underlying mechanisms simply don't supply it. (XXX - add a list of system that supply the FCS and the systems that don't?)

XXX - 1GBit (10GBit?) Ethernet allows "Jumbo Ethernet Frames" of 9000? bytes, making the above standard Ethernet graphic inappropriate.

For operating system developers: it's considered to be a security threat to send uninitialised padding data!

For protocol developers: 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!

Even if the VLAN tag is 4 bytes, the minimum size of the Ethernet frame with VLAN tagging is 64 bytes.

MAC address fields

An Ethernet host is addressed by its Ethernet MAC address, a 6 byte number usually displayed as: 08:00:08:15:ca:fe (the delimiters vary, so you might see 08-00-08-15-ca-fe or the like).

The first three bytes of the address are assigned to a specific vendor or organization; they're referred to as an Organizationally Unique Identifier, or an OUI. See the IEEE OUI list, Ethernet numbers at the IANA, Michael A. Patton's list of vendor codes, and Wireshark's list of Ethernet vendor codes and well-known MAC addresses, from the Wireshark source distribution, for assigned OUIs. You can also search for a particular OUI from the IEEE OUI and Company_id Assignments page.

A destination MAC address of ff:ff:ff:ff:ff:ff indicates a Broadcast, meaning the packet is sent from one host to any other on that network.

A destination MAC address where the low-order bit of the first byte is set indicates a Multicast, meaning the packet is sent from one host to all hosts on the network interested in packets sent to that MAC address. A number of multicast addresses have been assigned; see Ethernet numbers at the IANA, Michael A. Patton's list of multicast addresses, and Wireshark's list of Ethernet vendor codes and well-known MAC addresses, from the Wireshark source distribution, for assigned multicast addresses.

The second least significant bit of the first byte is the "Locally Administrated" bit. This bit is always set to 0 for all assigned OIDs. The purpose of this bit is that if you change your MAC address you should also set this bit to 1 in the new MAC address so that it is clear it is not a factory default MAC address. Many, but not all, cluster configurations that utilize MAC address failover will set this bit to 1 for the failover interface.

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.

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. (According to the October 1988 issue of COURIER (page 8), "if it is less than 600H, the packet is assumed to be an 802.3 packet; if it is greater than 600H, the packet is flagged as an Ethernet packet.")

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 (XXX - slight duplicate of sentence above?).

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.

(XXX - we should mentioned that the 802.2/802.3 terminology used by Netware at that time is simply confusing)

Some examples of values in the type/length field:

  • 0 - 45 invalid
  • 46 - 1500 length field (IEEE 802.3 and/or 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.

History

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 wireshark.org in a web browser.

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

Example capture file

Full capture from above example. Opening www.wireshark.org from the Firefox browser.

Wireshark

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

  • eth 

    all Ethernet based

    eth.addr==08.00.08.15.ca.fe 

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

    !(eth.addr==08.00.08.15.ca.fe) 

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

    eth.dst==ff:ff:ff:ff:ff:ff 

    Ethernet Broadcast only

    eth.dst!=ff:ff:ff:ff:ff:ff 

    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 

Ethernet traffic to/from a range of addresses:

  •  (ether[0:4]>=0x00804400 and ether[0:4]<=0x008044ff) or (ether[6:4]>=0x00804400 and ether[6:4]<=0x008044ff)

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.

Discussion

Maybe we should add dissection of the MAC address and the Multicast and the LocallyAdministrated bits. Since many clusters implement MAC failover and they create the "new" MAC address for the failover interface as the same MAC address as the primary interface but with the LA bit set to 1, we should also add code to strip this bit off when we try to map it to a OID name.

Ethernet (last edited 2011-04-25 22:24:29 by BillMeier)