Comment # 1
on bug 9236
from Guy Harris
(In reply to comment #0)
> although I don't know if the
> "type" value of 0x0034 is defined in any specific standard
It's not a valid Ethernet type value; as IEEE Std 802-2001 says in section 10.4
"Ethernet types: Format, function, and administration":
An Ethernet type value is a sequence of two octets, interpreted as a 16-bit
numeric value with the first octet containing the most significant 8 bits and
the second octet containing the least significant 8 bits. *Values in the range
0–1535 are not available for use.*
It later says, in section 10.5 "Encapsulation of Ethernet frames over LLC":
This subclause specifies the standard method for conveying Ethernet frames
across IEEE 802 LANs that offer only the LLC sublayer, and not the Ethernet
sublayer, directly above the MAC sublayer.
An Ethernet frame conveyed on an LLC-only LAN shall be encapsulated in a
SNAP PDU contained in an LLC PDU of type UI, as follows (see Figure 18):
a) The Protocol Identification field of the SNAP PDU shall contain a
protocol identifier in which
1) The three OUI octets each take the value zero.
2) The two remaining octets take the values, in the same order, of the
two octets of the Ethernet frame’s Ethernet type.
so that frame doesn't seem to be a valid SNAP-encapsulated frame.
Perhaps somebody's decided to "extend" SNAP so that an OUI of 00:00:00
("encapsulated Ethernet") and a protocol ID value < 1536 is an encapsulated
Ethernet frame with a length field rather than a type field, so that 0x0034 is
a length field with a value of 52 (octets); however, there are only 38 bytes,
not 52 bytes, following the length field.
You are receiving this mail because:
- You are watching all bug changes.