|
Size: 8292
Comment:
|
Size: 8305
Comment: Formatting
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 21: | Line 21: |
| === MAC address fields === | === MAC address fields === |
| Line 23: | Line 23: |
| 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, see [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] at the ["IANA"] and [http://www.cavebear.com/CaveBear/Ethernet/vendor.html Michael A. Patton's list of vendor codes] for assigned vendor codes, and see [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] and [http://www.cavebear.com/CaveBear/Ethernet/multicast.html Michael A. Patton's list of multicast addresses], for assigned multicast addresses. | 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, see [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] at the ["IANA"] and [http://www.cavebear.com/CaveBear/Ethernet/vendor.html Michael A. Patton's list of vendor codes] for assigned vendor codes, and see [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] and [http://www.cavebear.com/CaveBear/Ethernet/multicast.html Michael A. Patton's list of multicast addresses], for assigned multicast addresses. |
| Line 25: | Line 25: |
| A destination MAC address of ff:ff:ff:ff:ff:ff indicates a ["Broadcast"], meaning the packet is send 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 send from one host to any other on that network. |
| Line 27: | Line 27: |
| XXX - also describe multicast. | XXX - also describe multicast. |
| Line 29: | Line 29: |
| === Type / Length field === | === Type / Length field === |
| Line 31: | Line 31: |
| 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. | 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. |
| Line 33: | Line 33: |
| 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 35: | Line 35: |
| 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. | 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. |
| Line 37: | Line 37: |
| 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.) | 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.) |
| Line 39: | Line 39: |
| 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. | 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. |
| Line 41: | Line 41: |
| 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 43: | Line 43: |
| Some examples of values in the type/length field: | Some examples of values in the type/length field: |
| Line 45: | Line 45: |
| * 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 |
* 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 |
| Line 52: | Line 52: |
| See [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] and [http://www.cavebear.com/CaveBear/Ethernet/type.html Michael A. Patton's list of Ethernet type codes] for a list of assigned Ethernet type codes. | See [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] and [http://www.cavebear.com/CaveBear/Ethernet/type.html Michael A. Patton's list of Ethernet type codes] for a list of assigned Ethernet type codes. |
| Line 54: | Line 54: |
| === Frame Check Sequence (FCS) field === | === Frame Check Sequence (FCS) field === |
| Line 56: | Line 56: |
| 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. | 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. |
| Line 60: | Line 60: |
| * 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 64: | Line 64: |
| * Ethernet is the lowest software layer, so it only depends on hardware. | Ethernet is the lowest software layer, so it only depends on hardware. |
| Line 68: | Line 68: |
| Small portion of the capture from opening ethereal.com in a web browser. | Small portion of the capture from opening ethereal.com in a web browser. |
| Line 85: | Line 85: |
| Full capture from above example. Opening www.ethereal.com from the Firefox browser. | Full capture from above example. Opening www.ethereal.com from the Firefox browser. |
| Line 107: | Line 107: |
| Capture only the Ethernet-based traffic to and from Ethernet MAC address 08:00:08:15:ca:fe: {{{ | Capture only the Ethernet-based traffic to and from Ethernet MAC address 08:00:08:15:ca:fe: {{{ |
| Line 112: | Line 113: |
| * 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)
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 [http://standards.ieee.org/getieee802/802.3.html 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.
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, 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 ===
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, see [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] at the ["IANA"] and [http://www.cavebear.com/CaveBear/Ethernet/vendor.html Michael A. Patton's list of vendor codes] for assigned vendor codes, and see [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] and [http://www.cavebear.com/CaveBear/Ethernet/multicast.html Michael A. Patton's list of multicast addresses], for assigned multicast addresses. A destination MAC address of ff:ff:ff:ff:ff:ff indicates a ["Broadcast"], meaning the packet is send from one host to any other on that network. XXX - also describe multicast. === 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 [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. 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 [http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html 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 [http://www.iana.org/assignments/ethernet-numbers Ethernet numbers] and [http://www.cavebear.com/CaveBear/Ethernet/type.html Michael A. Patton's list of Ethernet type codes] for a list of assigned Ethernet type codes. === 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 [http://en.wikipedia.org/wiki/Ethernet#History 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 ethereal.com 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.ethereal.com from the Firefox browser.
- attachment:ethereal.com.pcap
Ethereal
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 [http://www.ethereal.com/docs/dfref/e/eth.html display filter reference]
Show only the Ethernet-based traffic:
eth
Show only the Ethernet-based traffic to and from Ethernet MAC address 08:00:08:15:ca:fe:
eth.addr==08.00.08.15.ca.fe
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
External links
A lot of tutorial information about Ethernet can be found at [http://www.ethermanage.com/ethernet/ethernet.html Charles Spurgeon's Ethernet Web Site].