Ethernet 802.2 vs. Ethernet 802.3
Articles and Tips: qna
01 Jun 2001
Q.
Dear Ab-end: Could you please explain why I should use Ethernet 802.2 instead of Ethernet 802.3? -- Confused about Frame Types in Farmington
A.
Dear Confused: Novell's ETHERNET_802.3 complies with IEEE 802.3 in that it defines a 1514-byte max packet size, where the first six bytes are the destination address, the next six bytes are the source address, and the next two bytes are a length field. But it's missing an 802.2 header, which could tell you what protocol is being run. Implementors "cheat" today by counting on the fact that ETHERNET_802.3 follows with a "-1" checksum field (0xFFFF). Since most popular protocols don't use a DSAP or SSAP field of 0xFF, you can add code to distinguish IPX running on an ETHERNET_802.3 frame from something else.
Ethernet 802.2 provides checksums, and doesn't have the same potential to crash servers as 802.3 does. To understand why this is, you should understand how Novell implemented 802.3 frames on NetWare.
In a typical packet, there are several fields in the header; two of those fields identify the checksum (2 bytes) and the protocol ID (1 byte). When 3Com and others first developed Ethernet, they didn't make the entire specification public, so Novell had to reverse-engineer the frame format in order to support it. They ended up with a 2-byte field and a 1-byte field that they didn't know the purpose of. The 2-byte field didn't look like it was being used, so they put a value of 0xFFFF in that field and wrote NetWare to identify frames with such a format as IPX traffic.
The problem a server can run into is that a non-IPX packet hits the server over 802.3 with a valid checksum of 0xFFFF. This is extremely rare, but it's still possible. The LAN driver passes this up the protocol stack to IPX, rather than to the correct protocol. Then, when decoding the packet, which is formatted for a different protocol, the possibility exists that the instructions in the packet are something along the lines of "send me the next 1 quadrillion bytes of information in the buffer." With NetWare 4.x, that'll most often result in a PFPE abend.
The extra time required to calculate the checksums means that Ethernet 802.2 is a little slower than 802.3. Because of the way NetWare uses that checksum field in 802.3, though, you cannot enable checksums on those frames, and you still can end up with corrupt packets getting to the server. All in all, 802.2 is more stable, gives you the checksums, and is now the standard frame type for Ethernet on NetWare.
For more information, see Don Provam's excellent explanation of all things Ethernet at http://netlab1.usu.edu/novell.faq/nvfaq-l.htm#L000.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.